cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: svn commit: r330329 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal: coplet/ layout/ layout/renderer/aspect/impl/ layout/renderer/impl/ persistence/castor/
Date Thu, 03 Nov 2005 08:30:30 GMT

Carsten Ziegeler wrote:

>Ralph Goers wrote:
>>And what about the case that I added support for - full screen with all 
>>the navigation still present?
>Actually, your changes broke the full screen feature if no tab is
>available. If you look at the current portal demo, full screen does not
>work anymore in the anonymous section as there is no tab.
Ouch. Well I could look into fixing that tomorrow. It needs to work in 
2.1 and I presume the changes below are only going in trunk.

>>Or is that what you are calling max-paged
>>(I get realy confused by this since the default 2.1 behavior is 
>The new possibilities are min/norma/full-screen-no-nav/max-paged where
>max-paged is a full-screen with static parts (= navigation and important
>>Frankly, the static layout thing sounds 
>>like it could get to be quite a pain. I really don't want to have to add 
>>an attribute on every single tab to say it should always be shown.
>Yes, for sure. We will have default values for each layout object. And
>the default for a tab will be static=true. So actually you shouldn't
>have to add an attribute at all.
>I suggest, just give me some more days to implement this stuff. Then we
>all can have a look at it and decide if it's a good thing or if it's
>crap. And then perhaps we see what we really need.
>But as I said, we have the use case for full-screen (= one single coplet
>without any navigation) and max-paged. Perhaps max-paged is a wrong or
>misleading term?
Well, JSR-168 (almost) defines NORMAL, MAXIMIZED and MINIMIZED.  
Unfortunately, both full-screen and max-paged meet the definition of 
MAXIMIZED so it isn't clear what behavior a portlet should exhibit in 
that case.  In addition, JSR-168 allows us to define other window 
states.  So I would suggest that whatever window states are supported 
that they be done in such a way that they can eventually be used by 
JSR-168 portlets as well as coplets. 

>Hmm, I thought if preferences are changing, the coplet instances data
>are only saved and not the layout?
After looking at the code I guess your right - we only write out the 
coplet instances data. That isn't a problem for me now, but I imagine it 
will be for some users.

>But you're right that it's not good to save the whole bunch of data. We
>should provide the information about what changed to the persistence
>layer and it's then up to the layer to decide to save the whole profile
>or just the changed information.
As I recall this was partly an artifact of the way that pluto stores 
preferences. I believe pluto starts the process by calling So unless we keep track of the parts that 
have changed ourselves we don't know what has changed and so we write 
the whole thing. However, I believe it is worse than that because we end 
up using Castor to generate the XML and it, of course, is going to want 
to generate the whole document.


View raw message