[development] The menu - does it have to be different on each
ber at webschuur.com
Wed Aug 30 11:17:54 UTC 2006
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 :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060830/2e8bebe8/attachment-0001.pgp
More information about the development