[development] Splitting hook_menu into hook_menu and hook_router

[Earl Miles]

Dries Buytaert wrote:
>  1. Do we have an idea of how many non-visible menu items there are?

A simple grep MENU_CALLBACK * | wc -l provides '67' as a first pass guess.

>  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.

For my purposes, I consider those to all be visible menu items; a further 
enhancement could eliminate the loading of items that are collapsed, which 
would be even better.

>> 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.

This isn't fully true in our current system, at least with tabs.

But even so, this is a philosophy, and should be enforced as such. i.e, code 
checked into Drupal core should match this philosophy, but should we actually 
force other people's sites into this mold? This is especially true if a site is 
choosing not to use breadcrumbs (...like most sites I know).

For a completely mythical example, let's say I have an information page on my 
site that is properly named "The hoobar splotchets from the Village of Nom". 
That's fine for a page title, but boy that's a long menu title. Especially if 
my site's design has very little space for the menu.

I have no quarrel with Drupal sticking to this as a philosophy in core and the 
like, but I am not so keen on forcing that philosophy on other people's sites.

>> 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.

This is incorrect for two reasons.

First, your solution creates two different places with the same content. We 
know from SEO work that google doesn't like this, but even without that...if 
the URLs are different, there are other factors that make it a different place. 
And you can't, in the current system, have the same path in the menu tree twice.

Two, even if that works, I can't, via hook_menu(), put my items in the Primary 
Links navigation menu.

>> 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".

Except that node/* is automatically out of the schema of wherever we might want 
that content to be, just to grab an easy to see example. In this case, aliasing 
helps this somewhat, but not completely, and pathauto isn't part of core in any 
case. There are a lot of contrib modules that exist to address this as an issue.

But sometimes, something might simply logically go in two places, because 
classification isn't always as clean as we want it. This is why we have two 
views for the administration page now. By Task and By Module.

>> 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.

I haven't given this enough thought to provide a truly good answer, but ideally 
with a proper parenting system, you'd largely have a setting that says "This is 
a tab of...", and the 'default' tab wouldn't need the 2 entries it does now. 
And without specifying a parent theoretically it could fall back on the URL for 
determining what the tab's parent would be. This needs more thinking than I 
have time to put into it now, unfortunately.