> 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 >
