cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
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 12:52:29 GMT
Ralph Goers wrote:
> 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.
Yes, all new features are just going to trunk.

> 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.
Yes, I think we can map max-paged to MAXIMIZED and full-screen to
something else.

> 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. 
Yes, good idea.

>>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.
I think we should keep track of the changed parts. As store() is invoked
it shouldn't be that difficult.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message