AS> Gang - AS> On 11/4/10 2:14 PM, Ed Burns wrote: EB> Andy, if you want to suggest alternate, and more high level, spec EB> language, please feel free to do so, but as you know it may not get into EB> the final 2.1 spec due to time constraints. EB> EB> I will currently undertake a drastic simplification of the spec language EB> for this feature, AS> Ed and I had a quick chat offline. We agreed that simplification is the AS> way to go. I would be happy with something along the lines of this: I have taken this text verbatim with one exception, shown here. EB> If this property is set to true, the UIData will take steps to ensure EB> that modifications to its iterated children will be preserved on a EB> per-row basis. This allows applications to modify component EB> properties, such as the style class, for a specific row, rather than EB> having such modifications apply to all rows. EB> EB> To accomplish this, UIData calls saveState() and saveTransientState() EB> on its children to capture their state on exiting each row. When EB> re-entering the row, restoreState() and restoreTransientState() are EB> called in order to reinitialize the children to the correct state for EB> the new row. I added a sentance here: All of this action must take place during processing of setRowIndex(). I'm sorry, Andy, but I want to be a little more specific. EB> once we introduce the new and improved UIData state saving mechanism, EB> UIComponent.saveState() will be called at multiple points in time: EB> EB> 1. During state saving (the traditional case). EB> 2. In response to UIData.markInitialState(). EB> 3. In response to UIData.setRowIndex(). EB> It seems like we'll need some way to distinguish between these cases. AS> Ed reminded me that we have already added a way to detect this. AS> Unfortunately, it is specific to tree visiting. From VisitHint: EB> /** EB> * <p class="changed_added_2_1">Hint that indicates that the visit is EB> * being performed for state saving purposes.</p> EB> * EB> * @since 2.0 EB> */ EB> EXECUTE_STATE_SAVING AS> While this visit hint was added at my request, I now realize that the AS> requirement for knowing whether we are performing state saving is more AS> generic than tree visiting. As such, I would like to ask that we: AS> 1. Remove this VisitHint value. And... AS> 2. Add an equivalent FacesContext attribute AS> #2 will make it possible to address the concerns that I raised regarding AS> Trinidad view root caching compatibility and may be useful in other AS> scenarios as well. AS> If anyone has objections to this, or suggestions for the AS> setRowStatePreserved() specification, please let us know as soon as AS> possible. Ed will be handing off the specification to the JCP very soon! I have committed this. Many thanks to Ken Paulsen for his code review. Now that JSF is a hobby for him, and not a day-job, I really appreciate it. Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 3 work days until German Oracle User's Group Conference | 10 work days until GlassFish 3.1 Hard Code Freeze