[development] Splitting hook_menu into hook_menu and hook_router

[Dries Buytaert]

On 18 Jan 2007, at 21:23, Earl Miles wrote:
> However x2, you won't load non-visible menu items that aren't being  
> used *at all*; they will remain safely tucked away in the database,  
> not eating memory except when used. Only the *visible* portion of  
> the menu tree would be loaded. This, some saved memory.

Yes!  Good point, Earl.  Two remarks though:

  1. Do we have an idea of how many non-visible menu items there are?
  2. You'd still need a little bit of information about the non- 
visible menu items.  For example, for each visible menu item, you'll  
want to know if it has visible children that you have access to.  You  
need that kind of information to determine whether the menu items is  
a leaf, or whether it can be folded/collapsed.

> By disconnecting the visible menu from the router...
>
> 1) ...the menu title and the page title no longer need to be the same.

We choose to make page titles and menu titles identical because it is  
considered good practice from a usability point of view.  This was  
suggested by usability experts.  By forcing them to be the same, we  
enforce good behavior.  It's one of the things I _really_ like about  
the current menu system.  Decoupling both is a regression, and not a  
step forward.

> 2) ...we will no longer have that very frustrating bug where adding  
> a protected menu entry to the visible menu would remove all access  
> controls to the item.

Agreed.

> 3) ...we make it easier to have multiple menu items go to the same  
> place. Karoly has mentioned this several times, but I believe it is  
> important to re-iterate, because it matters a great deal.

In the current system, you'd just create a second menu item and point  
it to the same callback.  How would this system make it easier?   
Simply because you'd need to duplicate less code?  It would be great  
if we could see an actual example of how this becomes easier.

> 4) ...we make it easier to control where in the hierarchy your menu  
> item actually falls. Right now that's all very automatic based upon  
> the path. Which is all fine, but sometimes that's not what the  
> developer wants, but the developer has no control over it.

This, too, encourages a consistent and structured URL schema.  I like  
it when my navigation structure and URL schema are aligned.  It makes  
for URLs that are easy to discover and remember.  I'd hate it when  
the navigation structure and the paths would be "out-of-sync".

> 5) ...we'll reduce the complexity of coding for tabs. Coding for  
> tabs doesn't make a lot of sense right now, we're fairly limited in  
> what we can do with them vs what users expect of them.

I agree that creating tabs is somewhat cumbersome.  I'd love to see  
an example of how you'd do tabs in the proposed system.  I have a  
hard time imaging how it would work, and thus, why it would be better.

--
Dries Buytaert  ::  http://www.buytaert.net/