[development] Splitting hook_menu into hook_menu and hook_router

[Dries Buytaert]

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/