Re: [jsr-314-open-mirror] [jsr-314-open] [153-UIDataStateSaving] spec clarifications requested by Andy
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