Re: Some questions regarding state-saving of components and Backing-Beans

[Simon Kitching <sk...@apache.org>]

On Tue, 2006-01-17 at 02:17 +0100, Matthias Kahlau wrote:
> Hi!
> 
> 
> I have some questions regarding the state-saving mechanisms of MyFaces.
> 
> 1) Do the MyFaces state-saving mechanisms (client-side/server-side) differ
> in any way from the behaviour defined in the JSF 1.1 spec? Are there any
> additional configuration options?

There are enhancements available.

There is a mechanism where N old view trees are cached, so that browser
"back" button can work. I don't know the details of this though.

In addition, the JSF 1.2 "encrypted client state" feature has been added
to MyFaces, so that when client-side state saving is enabled the data
can be encrypted with a key.
  http://wiki.apache.org/myfaces/Secure_Your_Application

> 
> 2) Does anybody know a good source explaning the state-saving mechanism of
> Backing-Beans, e. g. are the beans always serialized? Is this behaviour
> configurable, and/or does it depend on the application server?

Backing beans are never serialized by standard JSF; the serialization
done is for *JSF components only*.

The tomahawk t:saveState does cause the object specified to be
serialized along with the view; see the documentation for t:saveState
for details.

> 
> 3) Is it true that only t:saveState does provide the possibility of saving
> the state of whole Backing-Beans in the response?

The only thing in myfaces that does this is t:saveState.

Apache Shale presumably has a state-saving mechanism for its "dialog"
stuff. JBoss Seam presumably has something similar too.

> 
> 4) If I use t:saveState for a request-scoped Backing-Bean, which may have
> some references to other Backing-Beans in session scope, isn't the state of
> the referenced Backing-Beans stored both in the response and in the session,
> and inversely?

Yep. So you'd better not do that.

You could declare the references from your saved bean to the other beans
as transient. In the backing bean's constructor, then perform lookups to
restore the links to the longer-lived beans:

Or you could *not* save the backing bean, and instead put the data you
want to save into a member of that bean. Save that member, and let the
request-scope backing bean be recreated on each request.

See:
  http://wiki.apache.org/myfaces/FAQ#Bean

Regards,

Simon

Re: Some questions regarding state-saving of components and Backing-Beans

[Carsten Stiller <ca...@tu-ilmenau.de>]

Simon Kitching wrote:

> There is a mechanism where N old view trees are cached, so that browser
> "back" button can work. I don't know the details of this though.

Does anyone know where to find more details about this? This is one of 
our major problems at the moment. Does it also work with server side 
state saving?

MyFaces should somehow "know" from which view the request came. But as 
it's not guaranteed that the same IDs doesn't occur in different views I 
can't imagine how this will work.

Any help is welcome.


Carsten

AW: Some questions regarding state-saving of components andBacking-Beans

[Matthias Kahlau <mk...@web.de>]

> The tomahawk t:saveState does cause the object specified to be
> serialized along with the view; see the documentation for t:saveState
> for details.

I have a problem with updating an domainmodel object's state which is
referenced from within a Backing-Bean saved with t:saveState. I think the
update problem might be caused by serialization of the Backing-Bean.

The reference of the saved Backing-Bean of form 2 to the domainmodel object
is obtained by a method call of the Backing-Bean from form 1, which prepares
the page/form 2 to be displayed.

To leave form 2 to form 1 an action method of the saved Backing-Bean of form
2 can be invoked, which updates the domainmodel object by the reference it
has obtained. The updated domainmodel object is then shown in form 1.

The problem was that the state of the domainmodel object shown in form 1
after updating was not updated. The changes made to the domainmodel object
from the Backing-Bean of form 2 before showing form 1 were not reflected.

To solve that problem, I had to explicitely update the reference to the
domainmodel object from the Backing-Bean of form 1 after updating it in the
Backing-Bean of form 2.


Can you also imagine that this might be caused by the serialization of the
domainmodel object, or do you have some other ideas?


(I hope you can understand my explanation...)


Regards,

Matthias


> -----Ursprüngliche Nachricht-----
> Von: users-return-15346-mkahlau=web.de@myfaces.apache.org
> [mailto:users-return-15346-mkahlau=web.de@myfaces.apache.org]Im Auftrag
> von Simon Kitching
> Gesendet: Dienstag, 17. Januar 2006 02:39
> An: MyFaces Discussion
> Betreff: Re: Some questions regarding state-saving of components
> andBacking-Beans
>
>
> On Tue, 2006-01-17 at 02:17 +0100, Matthias Kahlau wrote:
> > Hi!
> >
> >
> > I have some questions regarding the state-saving mechanisms of MyFaces.
> >
> > 1) Do the MyFaces state-saving mechanisms
> (client-side/server-side) differ
> > in any way from the behaviour defined in the JSF 1.1 spec? Are there any
> > additional configuration options?
>
> There are enhancements available.
>
> There is a mechanism where N old view trees are cached, so that browser
> "back" button can work. I don't know the details of this though.
>
> In addition, the JSF 1.2 "encrypted client state" feature has been added
> to MyFaces, so that when client-side state saving is enabled the data
> can be encrypted with a key.
>   http://wiki.apache.org/myfaces/Secure_Your_Application
>
> >
> > 2) Does anybody know a good source explaning the state-saving
> mechanism of
> > Backing-Beans, e. g. are the beans always serialized? Is this behaviour
> > configurable, and/or does it depend on the application server?
>
> Backing beans are never serialized by standard JSF; the serialization
> done is for *JSF components only*.
>
> The tomahawk t:saveState does cause the object specified to be
> serialized along with the view; see the documentation for t:saveState
> for details.
>
> >
> > 3) Is it true that only t:saveState does provide the
> possibility of saving
> > the state of whole Backing-Beans in the response?
>
> The only thing in myfaces that does this is t:saveState.
>
> Apache Shale presumably has a state-saving mechanism for its "dialog"
> stuff. JBoss Seam presumably has something similar too.
>
> >
> > 4) If I use t:saveState for a request-scoped Backing-Bean,
> which may have
> > some references to other Backing-Beans in session scope, isn't
> the state of
> > the referenced Backing-Beans stored both in the response and in
> the session,
> > and inversely?
>
> Yep. So you'd better not do that.
>
> You could declare the references from your saved bean to the other beans
> as transient. In the backing bean's constructor, then perform lookups to
> restore the links to the longer-lived beans:
>
> Or you could *not* save the backing bean, and instead put the data you
> want to save into a member of that bean. Save that member, and let the
> request-scope backing bean be recreated on each request.
>
> See:
>   http://wiki.apache.org/myfaces/FAQ#Bean
>
> Regards,
>
> Simon
>