[development] Splitting hook_menu into hook_menu and hook_router
dries.buytaert at gmail.com
Wed Jan 17 17:48:43 UTC 2007
On 16 Jan 2007, at 23:04, Karoly Negyesi wrote:
> hook_router has these things:
> -- path as primary key. We use this as an array key, so an alter
> hook can easily be provided.
> -- access callback and arguments
> -- page callback and arguments
> -- map callback and arguments
> hook_menu has these:
> -- path. This is not unique. It's often requested that one path
> could have more than one visible link.
> -- parent. If you omit this, it can be autogenerated but for
> setting it to some arbitrary value, let's say MENU_ROOT can be used
> to indicate a new menu. With this (or via other means if someone
> has a better idea) we can put links into any menu.
> -- title.
> -- weight.
> -- expanded.
> With path being unique in one and not unique in the other ...
Care to give a concrete example of where it goes wrong? I think
you'll want to elaborate on this a bit more. While you highlight
some differences, it is not clear what the advantages are other than
logical separation. While logical separation is a good thing, both a
menu and a router would have to do access control. Looks like they
might be some overlap in functionality, if you split them?
Btw, the 'page callaback' vs 'map callback' is going to be a source
of confusion. It is not very natural/intuitive. Is there a way to
make it redundant or self-explanatory? Making the menu system
accessible to developers is an important goal, so if we can
brainstorm a bit more about that -- that would be great. Most people
don't care all that much about memory usage and performance -- they
care about clean APIs and code that is easy to grok.
Dries Buytaert :: http://www.buytaert.net/
More information about the development