Manfred Geiler wrote:
Purpose of <x:saveState> is to save the value of the property of a bean in request scope. It is a convenient way to preserve values between requests when you are using client side state saving and you do not want to use session scope beans.
If you want to save values "over a longer period of time", i.e. between multiple requests on different pages, i.e. different request scopes (!) you must either:
- use session scope for your beans, or
- use the same <x:saveState> on every page (of concern)
Strange, the funny thing is, I noticed, that if you have a request saveState seems to be unnecessary since the data is preserved between the request calls...
ie:
<h:form>
<h:textField value="#{bean.myVal}"/>
.......</h:form>
pushes the value into the successing bean.myval automatically after a submit and the value is pushed back into the control after the action is done if you stay in the same page or go into a different page which accesses the same bean (bean of course has request scope)
At least as long as you have forms the saveState seems to be uneccessary.....
Am I right, that saveState only makes sense if the data has to be preserved in a formless page or in a page where the bean is not accessed ? Like in following scenario:
Page a has form... submit pushes the data into the bean and then the data is processed and then page b is forwared Page b is formless, it needs the saveState fields to preserve the data from page b a link is set back to page a
once the link is pressed thanks to the saveState a can be filled again with the old values...
Is this assumption correct?
You can even simulate sessions without actually using ServletSessions. That's what I do in some of my applications:
I have a Model Bean called "sessiondata". This bean has properties for all those values that would normally go into the Session object. On the top of every single JSP I include
<x:saveState id="sd" value="#{sessiondata}"/>
The SessionData class itself must be serializable, of course.
Works like a charm. And if you are using Tiles you only need to add the <x:saveState> once in your master layout tile page.
Manfred
Yes... I can see that I am not sure if this approach is better
than mine to solve the Problem... I simulate a limited session, with a fixed amount of entries (like 10 objects) the data is pushed into this limited scope and once it a certain amount of objects are pushed in
the oldest one is dumped (that happens on the codeside of things)....
Thus you dont run out of memory due to excessive user request and you dont have to drag form data constantly with you through the
pages...
