1. Router system with access control.
1. Tabs with access control.
1. Menu links
These three have little to do in common and yet we keep them together. I separated the two access controls because it's not always the same and while most of the time it's a permission for paths, it's almost never a permission for tabs. Tab work is at http://drupal.org/node/484234 .
Menu links should be simply saved from install files and not generated from router.
-----------
"saved from install files" -> how do you imagine that? hook_install()
I think this would be a mess, if now every module has to deal with "if this item already exists" etc.
------------
This is how I (donquixote) would build the system (heck, why is this a wiki page?):
- Router items are declared with hook_menu() + hook_menu_alter() or something similar. Yes, it would make sense to rename this stuff to hook_routes() + hook_routes_alter() or similar.
- Modules or core functions can request a full or partial "menu rebuild", where router information is updated from hook_menu(). A partial rebuild would require that the module knows that only some hook_menu implementations are affected - which is a risky assumption.
- Router items can contain "hints" for building a menu tree. This is especially useful for adminstration pages: Nobody wants to spend time moving these around. And module maintainers don't want to have extra work in hook_install() to get the admin menu links right.
- Core does NOT automatically build a "navigation menu" or an "admin menu" on menu_rebuild(). It does NOT deal with things like "menu links re-parenting". We leave that to contrib.
- Contrib modules can react to menu_rebuild() by implementing hook_menu_router_built($router_items, $changes), where $router_items contains the up-to-date information from menu_router, and $changes contains information about which router items have been deleted, added or modified:
- Such contrib modules can produce a menu tree from what they find in router. They can write the result into the menu_links table, but they don't have to. Instead, they could store the generated tree in a cache variable, and/or output it directly.
- Contrib modules could build something that does not even fit into the menu_links system: Such as, (i) a menu subtree parameterized with the wildcard loader argument of the current page, or (ii) parameterized with the uid of the current user.
- Such contrib modules could invoke their own hooks that would allow to alter the structure that was generated this way.
- Tabs could be implemented in a similar way.