[jsr-314-open] Partial state saving + tree visiting

Gang - I have been spending time looking partial state saving lately - mostly trying to understand what Trinidad/ADF Faces need to do to fully support this. I have some questions regarding the use of tree visiting to save/restore partial state. This touches on implementation, though think it is important to have a consistent story, so sending to jsr-314-open. At the moment our implementations are somewhat mixed in how they handle the partial state traversals: - Mojarra 2.1 performs a tree visit for both the partial state save and restore traversals. - Mojarra 2.0 performs a tree visit for the partial state restore but uses a good old facets + children traversal for the save. - MyFaces 2.0 performs a facets + children traversal for both save and restore. I believe the reason for the inconsistency has to do with the fact that we did not have an explicit VisitHint.SKIP_ITERATION in 2.0. (Though, at some point last year we agreed to temporarily go with a FacesContext property until we could add the new VisitHint to the API.) As a result, the implementation teams avoided tree visiting (at least partially) in order to avoid unnecessary/incorrect UIData iteration. Now that we've got our visit hint in 2.1, in theory this should make the correct behavior clearer: we can now use tree visits for both the save and restore and specify the SKIP_ITERATION visit hint to avoid iterating over rows in iterating components. However, after thinking this through in more detail, I am not quite sure whether the correct behavior is as obvious as I originally thought it was. Here's why… One of the main benefits of tree visiting over a traditional facets + children traversal is that tree visiting allows components to be visited "in context" - ie. ancestor components can override visitTree() to set up context on behalf of their children. The most typical case is an ancestor setting up context that influences EL evaluation for the ancestor's subtree. We (ADF) have some cases where setting up context can be expensive and as such we'll want to avoid this work if not strictly necessary. More generally, we don't want to set up any tree visiting-related context during state saving/restoring since it is simply not necessary. We have never performed context set up/tear down during full state saving (ie. processRestoreState()/processSaveState() don't do anything interesting). There is no point in introducing this now for partial state saving. Doing so would introduce unnecessary overhead, plus result in inconsistent behavior between partial and full state saving. I had been thinking that the way to handle this is to have some way for our components to distinguish between visitTree() calls that occur for partial state saving/restoring purposes (in which case we don't want to set up context) vs. other tree visits (in which case we do want to set up context). As of 2.1, we have all of the APIs in place to allow us to do just this. In particular: - We can detect the partial state saving tree visit via the StateManager.IS_SAVING_STATE FacesContext property. - We can detect the partial state restoring tree visit by checking the phase id + VisitHint.EXECUTE_LIFECYCLE. (Though implementations will need to be sure to set this hint - logged Mojarra issue 1929 for this.) By examining these properties/hints, a visitTree() implementation can make an informed decision about whether it is necessary to set up context. While it is now possible for visitTree() implementations to do the right thing, I worry that this is overly complex and possibly unnecessary. If we want to: - Visit all (non-transient) components, but… - Skip iteration (for UIData-like cases). And… - Avoid setting up context. Is tree visiting even the right tool for the job? Should we perhaps avoid this complexity altogether by sticking with a facets + children traversal (eg. as currently implemented by MyFaces) for partial state saving/restoring? Or are there cases where component implementations do in fact need control over the way that this traversal is performed, in which case an internal iteration solution (like tree visiting) is necessary? Andy