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/