ah, I see. makes sense, --arjuna On 9/25/06, Adam Winer <[EMAIL PROTECTED]> wrote:
On 9/25/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote: > > > > > The preferred solution > > is making sure that we can simply cache the original UIViewRoot > > itself. But simply saving and restoring sufficient state should > > be enough, so I figure we could just call UIViewRoot.saveState() > > and UIViewRoot.restoreState(). > > > > do you mean something like this: remove all the children from the > UIViewRoot, then call restoreState() on it, *restoreState()*, not *processRestoreState()*. saveState() and restoreState() are single-component, not full tree. So no need to add/remove anything. -- Adam (so that we don't incur the cost of a full restoreState walk on the > component tree) > and then add the children on to the UIViewRoot again. > > > > And, In may case, redefine class for ViewRoot component in > > > faces-config.xml break after first restore tree state > > > > > > > > Yes, though that should be cleanly fixed simply by going through > > Application.createComponent() to create the UIViewRoot. > > > > good idea. that is a trivial fix. > --arjuna > > > On 9/25/06, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > On 9/25/06, Alexander Smirnov <[EMAIL PROTECTED]> wrote: > > > > > > I work for compability on Apache Trinidad and ajax4jsf project, and, > > > after solve all My problems have one incompability with client-side > > > saving state. > > > As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore > > > state methods, but manager simple created new instance of UIViewRoot > > > class, and copy any properties from cached instance to new. This code > > > will be source of problem in any realisations expect SUN RI 1.1 - > since > > > in MyFaces and JSF 1.2 implementations viewRoot have more persistanse > > > parameters ( at least, must be restored unique id's counter, and lot > of > > > listeners in JSF 1.2 ). > > > > > > We wanted to simply cache the UIViewRoot itself, but there were > > problems in JSF 1.1 with events (and maybe also messages?) > > not getting cleared. So, you have a pending ActionEvent in > > the queue, but validation fails - then you get two ActionEvents > > the next time around! > > > > This led to us re-creating the UIViewRoot. The preferred solution > > is making sure that we can simply cache the original UIViewRoot > > itself. But simply saving and restoring sufficient state should > > be enough, so I figure we could just call UIViewRoot.saveState() > > and UIViewRoot.restoreState(). > > > > I'm willing to add a configuration flag to disable this optimization - > > which > > is a very significant one - but would not want to turn it off by > default. > > > > And, In may case, redefine class for ViewRoot component in > > > faces-config.xml break after first restore tree state > > > > > > Yes, though that should be cleanly fixed simply by going through > > Application.createComponent() to create the UIViewRoot. > > > > -- Adam > > > > > >
