Hi cocooners First of all, thanks to Carsten and all the others contributors for this excellent portal engine with skin capabilities. But it seems that I reach the limit with menus handlers. I wanna use the portal for a big web site with the following functionalities: - a menu can have multiple level - a work area can be driven by more than one menu (i.e. horizontal, vertical, contextual) - a page can have more than one work area - a menu can have more than one render (i.e. dhtml and text) My first idea was to write a new renderer, but from the point of view of a cocoon's user isn't a piece of cake because you have to solve: - miscellaneous parameters in cocoon.xconf - database mapping for new tags in layout.xml - persistence of the selected item - and so on. But even with brand new renderers, I not sure to fill all functionalities. IMO the main restriction is the nest of XSL, driven by the composite-layout. You haven't a total freedom to organize the page as you want. Therefore the second idea is to consider menu like a regular coplet. A cocoon's user design its menus with its own pipelines and just configure new coplets - no more renderer to code, java to compile - and associate a menu item with an event id. The selected item can be store with the persistence mechanism of the coplet. The portal.xml becomes a flat list of all menu items by their event id with all composite-layout under to describe the page as usual. The main stuff to do is to associate a fixed event number to a menu item. The benefit will be to have also a bookmarkable portal. So, as a conclusion: does make sense? Laurent Trillaud
