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

[Bèr Kessels]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060830/2e8bebe8/attachment-0001.pgp