cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: pageLabel urls
Date Wed, 19 Oct 2005 19:49:12 GMT
Ralph Goers wrote:
> I think it would be OK to mark coplets as static, but I think the nav 
> should either just be there or not. I don't see the point in having to 
> add a static attribute to all the named items.  
You wouldn't mark each item, but the tab itself. Now, think of a layout
where you have a tab inside a tab. Perhaps you want that the inner tab
is "removed" when a portlet contained inside is maximized and the outer
tab layout should stay. Simple mark the outer as static (or if static is
the default, the inner one as not static) and that's it.

> This would also be
> pretty easy to implement. We could get rid of the entry layout altogther 
> and just use attributes on the "base layouts" (i.e. coplet, frame) to 
> figure out which ones to display. 
Yepp, that's exactly the idea. And this was how we implement it in the
first place. Now imagine that you have a hugh tree of layouts and down
the tree there is one layout/coplet that is now maximized. When you
start rendering the whole portal, you first have to crawl down the whole
tree to find out if there is a maximized coplet and if so, "move this up
the tree removing all non static parts". This is easy to implement but
in the end the three has to crawled several times completly and that's
not really nice. But in the end, this is the implementation detail. I
think it's important how it can be used and what it does :)

> I would prefere using "javax.portlet.event" instead of 
> "cocoon-portal-event" as javax.portlet is restricted for our use by JSR 
> 168, so there should never be a name clash with anything else.
Hmm, I personally like the "cocoon-portal-" more as this is in line with
request parameters form other blocks. But I plan to make this
configurable as well. Regardless of the name you use the portal will
take care, that those request parameters are never forwarded to jsr 168
portlets (or any other coplets).

Carsten Ziegeler - Open Source Group, S&N AG

View raw message