[development] Splitting hook_menu into hook_menu and hook_router

[Darrel O'Pry]

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.