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 > >
