[development] Splitting hook_menu into hook_menu and hook_router
dries.buytaert at gmail.com
Thu Jan 18 22:34:07 UTC 2007
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-
> 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
> 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
Dries Buytaert :: http://www.buytaert.net/
More information about the development