Its only in the main trunk. Since it is not fully tested and the next maintenance release is quite close I´ve not commited it into the 1.1.1 banch.
2005/10/19, ir. ing. Jan Dockx <[EMAIL PROTECTED]>: > About the branches: is this only in the main trunk, or also in the > 1.1.1 trunk (and thus will be in the RC3)? > > On 18 Oct 2005, at 22:06, Adam Winer wrote: > > > This sounds roughly like the implementation of server-side > > state saving in the JSF 1.2 RI, as well as what's done in ADF Faces, > > though not exactly, 'cause there's differences in the details (neither, > > for instance, supports putting sequence numbers into URLs, just > > hidden fields). > > > > What exactly do you mean by "the serialized view is now really > > serialized (this was not the case before)"? Before, server-side > > state saving (at least in 1.1 RI) was just stashing the UIViewRoot, > > which dies for a bunch of reasons. I'm gonna guess that > > you grab the SerializedView object with StateManager.saveState(), > > and then save off its two components. > > > > Getting per-request state to survive <redirect/>, like Mario's > > proposing, > > is a separate issue, as you say. > > > > -- Adam > > > > > > On 10/18/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: > >> Well, I have not taken a look into the ri for this issue. So I can not > >> say if it is solved like the ri. > >> > >> This is what I have done: > >> > >> If server side state is uses the serialized view is now really > >> serialized (this was not the case before) into the session by using > >> the viewid and a sequence number. The sequence number will be rendered > >> into the response (either as a hidden input field if used in forms or > >> as a param in a url). This sequence could also be used for other > >> things since it is increased by every request. The last sequence used > >> is also stored into the session. > >> > >> To restore the response the viewid and the sequenceid from the request > >> is used to determine the serialized view. The last 15 (currently fixed > >> number) views will be saved into the session. I´ve utilized a > >> ReferenceMap which uses SoftReference instances for the views after > >> the 15th. So if the garbage collector doesn´t collect these values > >> they are still available. > >> > >> I´ve done some testing so it seams to work. If anyone (maybe you > >> Marting ;)) finds the time to make some more tests I would be very > >> happy. > >> > >> Best Regards, > >> > >> Mathias > >> > >> 2005/10/18, Martin Marinschek <[EMAIL PROTECTED]>: > >>> Mathias, > >>> > >>> wow - you have solved the server side state saving problem we have > >>> had for ages? > >>> > >>> That will make some users very, very happy! > >>> > >>> Thanks from the whole team, great news indeed. > >>> > >>> Do you want to give us (on the dev list) a short wrapup on how you > >>> solved things? Did you keep close to the RI or did you implement a > >>> different solution? > >>> > >>> regards, > >>> > >>> Martin > >>> > >> > > > > > Met vriendelijke groeten, > > Jan Dockx > > PeopleWare NV - Head Office > Cdt.Weynsstraat 85 > B-2660 Hoboken > Tel: +32 3 448.33.38 > Fax: +32 3 448.32.66 > > PeopleWare NV - Branch Office Geel > Kleinhoefstraat 5 > B-2440 Geel > Tel: +32 14 57.00.90 > Fax: +32 14 58.13.25 > > http://www.peopleware.be/ > http://www.mobileware.be/ > > > -- Mathias
