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)
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.
If sessiondata bean is saved at "client", does it means when the site is crashed and if client gets back the the site after the crash, the client state of sessiondata is re-constructed and the client does not know?
yes.
What happens if sessiondata is also managed in the user session, i.e., if user does not have a session, a default sessiondata is created from jsf managed bean?
Yes.
Since sessiondata in this case is a normal request scope bean, it is automatically created on _each_ request.
After the crash, do you need to do anything to bring the client-site of <x:saveState> consistent with the sessiondata state in the user session?
No.
To give you some idea of what the <x:saveState> actually does, look at this code snippet from UISaveState:
public void restoreState(FacesContext context, Object state)
{
Object values[] = (Object[])state;
super.restoreState(context, values[0]);
Object value = values[1];
ValueBinding vb = getValueBinding("value");
if (vb != null)
{
vb.setValue(context, value);
}
}
So, during the "Restore states" phase, the UISaveState takes the saved client state (i.e the serialized bean itself or the serialized property value) and pushes it into to valuebinding.
HTH, Manfred
Thanks
BaTien DBGROUPS
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
Werner Punz schrieb:
Hi have a question regarding x:saveState.... I am not sure if I get it right... I am trying to enable following behavior... I have a form with x:saveState controls, to save the input over a longer period of time than a single request... The problem is, that once I move away from the form go to a different page within the same request scope and revisit the form the input values are no longer visible (instead the backing beans default values are set again)
The problem is easily reproducable by opening one of the examples (carcalc uses saveState extensively) then going to a different page and then revisiting the car calc form again...
I must be missing something here.
Kind Regards Werner Punz
