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