On Thu, 2007-01-18 at 13:37 +0100, Dries Buytaert wrote:
Still, I wonder why 5 people '+1'-ed the idea. I really like to understand so hopefully these people will motivate their vote so other can understand their reasoning/insights.
There are several things that make me agree with the concept of splitting menu and router. 1) Lower Barrier to Entry for Developers, Self Documenting Hooks. Hook_menu currently does two things. URL to callback dispatching and defining module provided menu items. It's a little counter intuitive. I thin splitting the functionality would make it easier to understand how Drupal handles initial page loading, without having to get into the details of building a visible menu. Two simple self explanatory API's are better than one confusing API. 2) Improved memory usage. People might not care about memory and performance on the surface, but ISPs care about server resource usage, site maintainers worry about the number of visitors their site can support and their hardware needs in relation to supporting their community, and site visitor care about how quickly the page loads. 3) Lighter Bootstrap. For cases like private files and xml-rpc interactions where the visible menu is not needed, there is less data to crunch before we get to the workhorse callback. I haven't really put too much thought into the deeper implications of the map callbacks, and alter hooks, but they seem like good tools for the examplecom.module I'm writing for example.com so I don't have to hack core to customize the site behavior. I could probably come up with more reasons I like the concept if I weren't hung over. .darrel.