[development] Splitting hook_menu into hook_menu and hook_router

[Dries Buytaert]

On 18 Jan 2007, at 23:03, Earl Miles wrote:
> 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.

I agree that we shouldn't limit what people can do.  Remind that you  
can actually overwrite the page title with drupal_set_title().  We  
have 'good default behavior' combined with the ability to overwrite  
that.  I'd like to keep that -- if possible.

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

True, but this doesn't actually invalidate my statement.  The obvious  
work-around is to do a drupal_goto() but let's not get into that.   
So, with the proposed system, it would just be slightly less code.

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

True, but this doesn't actually invalidate my statement.  Plus, as  
far as I can tell, this has nothing to do with separating the menu  
and router functionality in two functions.  It just a shortcoming of  
the current menu system.

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

Af far as I can tell, the same would be true for the new menu  
system.  With the current menu system. you can easily add nodes  
elsewhere in the menu tree.   Having a default path for each node is  
convenient.

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

Sure, but how would the router/menu separation simplify that compared  
to the current system.  As far as I can tell, you'd still need two  
routers and two menu items.

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

Again, a shortcoming of the current menu system but not necessarily  
related to splitting the router/menu.  Unless, maybe, I'm missing  
something.

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