IMO saving the state like jsf does is a very nice solution for this problem. I like it because it perfectly follows the OO paradigms and is easy to implement. I use it for our applications too. Whenever I have to handle table data where some fields needs to maintain a state for each row it is possible to hold the state for each field for a row through saveState/restoreState. I also use it for saving/restoring user preferences.
Do you use an other solution to store/restore the state of components? 2005/10/20, Simon Kitching <[EMAIL PROTECTED]>: > I'm still on the JSF learning curve, but I believe we're talking here > about saving the UIComponent tree state, and that that is done via a > custom approach in JSF. > > Firstly the JSF framework saves the classnames of the UIComponent object > tree, so that it can build an identical tree (but of new UIComponent > instances) when it needs to. > > Then each UIComponent object in the tree has its "saveState" method > called, which is expected to return an object array containing its > state. The UIComponent doesn't use java serialization; components with > no children typically just store the primitive values of its member > fields into an object array. Note that saveState can't use normal > serialization because the "component tree" has already been rebuilt by > the framework and that the return value of saveState is used to > *repopulate a particular UIComponent instance* (the one restoreState is > called on) rather than creating a UIComponent tree as deserialisation > would do. > > I don't know why this custom approach was used. > > If I'm on the wrong track, please let me know. > > Regards, > > Simon > > Adam Winer wrote: > > Ah, so you don't save the objects directly, you save the byte streams? > > > > That's excellent for development - it's a pain figuring out down the > > road that one object way down deep isn't serializable, and only when you > > try clustering right before going production :) - but seems like an > > unnecessary performance hit at deployment time. Perhaps a flag to > > switch between the two? > > > > -- Adam > > > > > > > > On 10/19/05, *Mathias Brökelmann* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > You are right the two objects in SerailizedView are serialized and put > > into the session. > > > > The instances of the server side state where not serialized before. > > This doesn´t affect the component instances since they are only > > referenced by class name in the state but it could have an effect on > > the state of the components. Some components may have statefull > > objects in their state (t:savestate for instance) > > > > The next thing is that clustering or a restart of the container is now > > better supported because the user will see a NotSerializeableException > > immediatly if a value of the state is not serializable. > > > > 2005/10/18, Adam Winer <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > > 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. > > > > > > -- > > Mathias > > > > > > -- Mathias
