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/
