[development] The menu - does it have to be different on each page?

[Brandon Bergren]

On Wed, 30 Aug 2006, Bèr Kessels wrote:

> Op woensdag 30 augustus 2006 01:28, schreef Moshe Weitzman:
>> now if we could determine callback without building the menu tree we would
>> be in real fine shape.
>
> Yea. Though interesting idea -rendering the whole tree- I feel it is "looking
> in the wrong area for a solution". The problem is not suc much the building
> of the whole menu vs building a part, the problem is that the menu-system is
> not designed to be optimised very well.

(Thought provoking questions, hopefully)

WWFAPID? (What would FormsAPI do?)

Would doing a more formsapi-ish approach make the code easier to read? 
Slower? Faster?

Why isn't the menu *always* a semi-static thing that modules get a chance 
to alter?

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?

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?


>
> Rendering a full menu brings in lots of problems, so I give it a big -1.
>
> * I looked around on some of my installs and found that some have over 600
> menu items. I'd hate to see them go over the line for every pageview.
> * Many  modules offer "dynamic" items. Including these in a static menu can
> let it grow over 70.000 items (that is the max I counted in a menu I have,
> with views and freetagging). No way that that will go over the line. A rough
> calculation brings me a menu HTML chunk of over half a Meg.
> * Depending on CSS and JS, greatly reduces themability and flexibility.
> Changing a few bits of CSS will require intimite knowledge of the way Drupal
> does the hiding/showing. And lots of nice, simple CSS tricks, such as hovers,
> background-images will no longer be possible, or else require a lot of CSS
> hacks, in order to co-exist with a core CSS system to hide menu parts.
> Advanced theme overrides (such as sliding door tricks, or putting the menu in
> tables etc) will become very cumbersome.
>
> I think we should look at a more robust solution, such as dropping
> the /path/hierarchy and embracing a parent-child relation system that lives
> in the database only. But I am sure people have better ideas than this :)
>
> Bèr
>

-- 
>From the mailer of
|_|0|_| B R A N D O N     B E R G R E N
|_|_|0|  T e c h n i c a l
|0|0|0|   G e n e r a l i s t  ( C S )