[development] Splitting hook_menu into hook_menu and hook_router
metzlerd at evergreen.edu
Fri Jan 19 16:50:23 UTC 2007
I think we'll need to think carefully about what it means to have two
different menu items tied to the same path. If these are in separate
parts of the menu tree, it creates some ambiguity about which parts of
the menu should be expanded and which shouldn't when a particular path
is gotten to. My prediction is that trying to resolve this ambiguity
will lead to some pretty messy code.
I agree tab coding needs cleaning up, but there are aspects of this
loose coupling that actually becomes harder when you separate the
concepts. If I navigate to example.com/admin/themes and that is
available say as a tab, and as separate menu item, how do I know whether
to display the tabbed context or not? I don't see how I can without
tightly coupling the concept of path and menu navigation.
So if we separate the router and the menu, I think the path needs to
stay with the menu, and not with the router. Maybe a route, can appear
at multiple paths? Let the route be more namespace-like:
I bet hook_menu_alter is possible without separating concepts of menu
and router, given that we're presenting drupal an array of menu items.
It might be more dangerouse, but it seems possible. :).
Finally having multiple links to a page does not necessarily imply that
you have multiple instances of the same path to the menu, it really just
means that you need links to a menu item to appear in multiple places.
From: development-bounces at drupal.org
[mailto:development-bounces at drupal.org] On Behalf Of Karoly Negyesi
Sent: Thursday, January 18, 2007 6:38 PM
To: development at drupal.org
Subject: Re: [development] Splitting hook_menu into hook_menu and
> > 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.
You indeed need two router items for the 'by task' and the 'by module'
However, what Merlin says is that these two pages prove that sometimes
two links eventually pointing to the same place are meaningful and
needed. The current administration menu is a mirror of the 'by task'
page and there is no way to have an 'administration by module' menu
because one page, one visible menu link is the current possibility. This
is not merely a minor shortcoming of the old menu or even the new menu
patch, both of which use path as a primary key -- router items naturally
have path as primary key as you just can't have two router items for the
same path and this needs to be enforced. As a side effect, we gain the
possibility of an easy and trivial hook_menu_alter.
More information about the development