cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laurent Trillaud" <ltrill...@jouve.fr>
Subject [RT] Portal Engine with multiple menus and multiple levels
Date Fri, 24 Oct 2003 13:55:29 GMT
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


Mime
View raw message