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

[Andy Schwartz]

Gang -

After thinking about this some more:

> One way to limit the impact of this is for components that hold onto 
> transient state to free up this state at the end of the request.  The 
> most obvious time to do this is when saveState() is called.  Now that 
> we are introducing a formal transient state solution, I would very 
> much like to see this transient state releasing behavior implemented 
> centrally - ie. it would very much help the view root caching 
> optimization if we could discard transient state when (non-transient) 
> state saving is performed.
>
> This should be trivial to implement - eg. in Mojarra, 
> ComponentStateHelper.saveState() could call transientState.clear().  
> However, if UIData's rowStatePreserved behavior requires that 
> saveState() is called before saveTransientState(), this would prohibit 
> us from clearing transient state during state saving, since this would 
> break transient state saving in the UIData case.  Swapping the order 
> around (save transient state first followed by non-transient state), 
> would at least allow the possibility of implementing this in a way 
> that would work well with Trinidad's view root caching.

I realized that the solution is not as simple as I originally thought.  
The problem is that 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().

Since Trinidad view root caching holds onto the component tree across 
requests, we really want to blow away transient state for #1.

However, we definitely do not want to blow away transient state in 
response to #2 - this state should survive the call to 
UIData.markInitialState().

I am not quite sure what the right behavior is for #3.

It seems like we'll need some way to distinguish between these cases.

Andy