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 )