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
> PortletEntityImpl.store(). 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
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
|