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