Good points, see comments below Brandon Bergren write:
... (Thought provoking questions, hopefully)
WWFAPID? (What would FormsAPI do?) $menu['menu'] = array( '#type' => 'menu', '#path' => array ('menu', 'yet', 'another', 'path', 'etc'), '#title' => t('Menu'), '#tree' => TRUE, '#collapsible' => TRUE, '#collapsed' => TRUE, ); $menu['menu']['item'] = array(' '#type' => 'node', '#nid' => 1337, '#title' => t('Node'), '#description' => t('A node item'), '#weight' => 5, ); $menu['menu']['item2'] = array(' '#type' => 'page', '#callback' => 1337, '#title' => t('A page'), '#path' => array(t('translatable'), t('path')), );
Would doing a more formsapi-ish approach make the code easier to read? Slower? Faster? Not sure
Why isn't the menu *always* a semi-static thing that modules get a chance to alter? If the code above is loaded in bootstrap it will be
Why is the menu responsible for paths, really? Wouldn't a seperate system for paths that could tell the menu to "expand to root" certain items work too? Couldn't modules take the menu object and tell it to expand the module's relevant roots, and then the module mark its own items as being active?
Why does the menu try to do everything itself? Why not delegate some stuff to the modules? IMO paths is rather related to menu items, or it should be... Why do modules publish individual menu items? Why not publish local roots and a callback for the menu system to get the children when needed? Wouldn't this make (taxonomy|category|whatever)_menu modules less bug prone?
Is there any reason the menu manager can't just become a *service* to modules? (i.e. an interface to let the admin (user even?) organize the children under module local roots?) Is the ability to move the originals around such a good idea? Why not make it easier to duplicate items instead? Could "alternate paths to this item" be stored in the menu item? Duplicates is not a good idea IMO, but it should be easier to duplicate/create shortcuts to menu items, without messing up the entire system