On 19 Oct 2005, at 9:51, Mathias Brökelmann wrote:
Its only in the main trunk. Since it is not fully tested and the next<x-tad-smaller>Met vriendelijke groeten,
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-sideMet vriendelijke groeten,
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
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
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
smime.p7s
Description: S/MIME cryptographic signature
