Hi Checking UIViewRoot class I have noted some side effect on UIViewRoot.processRestoreState() method.
The javadoc says this: ".....The default implementation must call UIComponentBase.processRestoreState(javax.faces.context.FacesContext, java.lang.Object) from within a try block. The try block must have a finally block that ensures that no FacesEvents remain in the event queue, and that the this.UIComponent.visitTree(javax.faces.component.visit.VisitContext, javax.faces.component.visit.VisitCallback) is called, passing a ContextCallback that takes the following action: call the UIComponent.processEvent(javax.faces.event.ComponentSystemEvent) method of the current component. The argument event must be an instance of PostRestoreStateEvent whose component property is the current component in the traversal......" Now just imagine a component inside h:dataTable and read the documentation of UIData.visitTree(). That algorithm visit child components per row. But UIData use the same component per each row and only save the values related to EditableValueHolder interface. The result is that we call PostRestoreStateEvent as many times as rows are available. This behavior of UIData.visitTree() has prevented me from using it for partial state saving, because we only need to call restoreState or saveState only once per component instance. In any case, It could be good to know if this behavior is expected or not. I tried to fix the behavior on myfaces of h:outputScript target="head" and partial state saving at postback with a listener to this event, but after reading the javadoc I notice it will not work as I expected. regards, Leonardo Uribe
