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

[Ed Burns]

>>>>> On Thu, 04 Nov 2010 16:28:44 -0400, Andy Schwartz <andy.schwartz at oracle.com> said:

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 at 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