[jsr-314-open] Tree visit hints [Was: ADMIN: Final list of issues for JSF 2.0 and actions for each]

Gang - While reviewing this list with Ed earlier this week, Ed and I discussed very small issue that is not mentioned in the list but which we agreed to at least consider fixing for 2.0. The issue is related to tree visiting and state saving. I believe that it is likely that certain components may need to visit their children in a somewhat different manner for state saving purposes - eg. a UIData may take different steps when visiting children for state saving as opposed to say, rendering an Ajax response. However, at the moment there is no way for a visitTree() implementation to know that state saving is being performed. visitTree() implementations do have access to the current phase id via the FacesContext, but of course state saving does not live in its own phase. In order to provide a way to inform visitTree() implementations that state saving is being performed, I proposed (to Ed) that we add a new visit hint. Currently we've got the following visit hints: I would like to add this new hint: While thinking about visit hints and UIData again, I got back to thinking about a use case that we had discussed in the past... Currently there is no way to tell components which visit their children multiple times (think UIData) not to bother performing iteration - ie. to only visit each child one time. So, for example, in the UIData case, there is no way to tell the UIData component to not iterate over each row when visiting children. At one point I had proposed a hint to provide control over this, but I never actually added this to the API. After discussing this with my colleagues internally here, we realized that we have at least one case where we need this ability. So, while I am in the VisitHint enum, I would like to also add the following new hint: I have opened up the following spec issue to track these requirements: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=545 And have also uploaded a patch which adds both of these APIs (though for the most part leaves the implementation alone). If anyone has comments/questions about either of these, please let me know. Ed - I realize that we did not discuss the SKIP_ITERATION proposal on our call. Please let me know if you feel that it is inappropriate to add this. I can upload a new patch. Andy