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