[jsr-314-open-mirror] [jsr-314-open] [153-UIDataStateSaving] spec clarifications requested by Andy

[Andy Schwartz]

Gang -

On 11/4/10 2:14 PM, Ed Burns wrote:
>
> Andy, if you want to suggest alternate, and more high level, spec
> language, please feel free to do so, but as you know it may not get into
> the final 2.1 spec due to time constraints.
>
> I will currently undertake a drastic simplification of the spec language
> for this feature,

Ed and I had a quick chat offline.  We agreed that simplification is the 
way to go.  I would be happy with something along the lines of this:


> If this property is set to true, the UIData will take steps to ensure 
> that modifications to its iterated children will be preserved on a 
> per-row basis.  This allows applications to modify component 
> properties, such as the style class, for a specific row, rather than 
> having such modifications apply to all rows.
>
> To accomplish this, UIData calls saveState() and saveTransientState() 
> on its children to capture their state on exiting each row.  When 
> re-entering the row, restoreState() and restoreTransientState() are 
> called in order to reinitialize the children to the correct state for 
> the new row.
>
> Users should consider enabling this feature for cases where it is 
> necessary to modify properties of UIData's children in a row-specific 
> way.  Note, however, that row-level state saving/restoring does add 
> overhead.  As such, this feature should be used judiciously.


I realize that this is much higher-level text than we had before, but my 
feeling is that we are much better off erring on the side of 
over-generalization than over-specification.

BTW, regarding:


> once we introduce the new and improved UIData state saving mechanism, 
> UIComponent.saveState() will be called at multiple points in time:
>
> 1.  During state saving (the traditional case).
> 2.  In response to UIData.markInitialState().
> 3.  In response to UIData.setRowIndex(). 
> It seems like we'll need some way to distinguish between these cases. 

Ed reminded me that we have already added a way to detect this.  
Unfortunately, it is specific to tree visiting.  From VisitHint:

>   /**
>    * <p class="changed_added_2_1">Hint that indicates that the visit is
>    * being performed for state saving purposes.</p>
>    *
>    * @since 2.0
>    */
>   EXECUTE_STATE_SAVING

While this visit hint was added at my request, I now realize that the 
requirement for knowing whether we are performing state saving is more 
generic than tree visiting.  As such, I would like to ask that we:

1.  Remove this VisitHint value.  And...
2.  Add an equivalent FacesContext attribute

#2 will make it possible to address the concerns that I raised regarding 
Trinidad view root caching compatibility and may be useful in other 
scenarios as well.

If anyone has objections to this, or suggestions for the 
setRowStatePreserved() specification, please let us know as soon as 
possible.  Ed will be handing off the specification to the JCP very soon!

Andy