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

[Ed Burns]

>>>>> On Wed, 3 Nov 2010 15:00:39 -0500, Leonardo Uribe <lu4242 at gmail.com> said:

EB> If the per-row state saved in step a. above is not null, traverse the
EB> children and restore the child state using the state saved during step
EB> a., using the initial rolled up state only as a backup in the case
EB> that per-row state is not available.

AS> Okay, so I guess that "per-row state saved in step a. above" refers to
AS> the previously saved state for the current row.

EB> No, it's the state before we adjusted the row index.  Leonardo, it is
EB> vitally important that you and Andy and I agree on this.

LU> The "per-row state saved in step a. above" in other words means the
LU> "delta" state from the row that will be changed. If we are on row 1,
LU> to change to row 2 we need to restore the state of row 2, and check
LU> if it is null or not, If it is null we use only the initial rolled
LU> up state, but if is not, we use both the initial rolled up state and
LU> the "per-row state saved".

After reading Leonardo's comments, I continue to believe that the text I
wrote in response to Andy's 19 October email is correct.  Here is the
relevant text from the UIData javadoc.  The latest Javadoc for that
class is attached.

EB> If the rolled up state saved during the call to markInitialState()
EB> is not null or empty, perform the reverse of the two save
EB> operations, as described next. This is necessary to indicate that
EB> transient state from the previous row must be discarded, in order to
EB> not pollute the state of the current row.


EB> * If the per-row state saved in step a. above (before we adjusted
EB>   the row index) is null, traverse the children and restore the
EB>   child state using the initial rolled up state.

EB> * If the per-row state saved in step a. above (before we adjusted
EB>   the row index) is not null, traverse the children and restore the
EB>   child state using the state saved during step a., using the
EB>   initial rolled up state only as a backup in the case that per-row
EB>   state is not available.

[...]

AS> Sounds like we are doing the same thing whether or not the transient
AS> state is null, so perhaps we can simplify the wording.

EB> Perhaps, but I'm concerned with getting it wrong.  The current text was
EB> approved by Leonardo so I'm inclined to go with it.

LU> In few words, it just say how to restore the "transient state". It
LU> is possible in this part I just forget to simplify things.

LU> The time I wrote that part I was thinking if there was some kind of
LU> manipulation on transient state properties before build view time,
LU> those values should be "propagated" to child rows, but the intention
LU> of this state is to have a very short life time (vdl build time or
LU> render time). If a value is necessary to be stored more than the
LU> current request, use StateHelper. After thinking about it carefully,
LU> the conclusion was that is not necessary, so we can just assume a
LU> "null" or "empty" state for the transient map.

Therefore, I will not take action to simplify the wording on this point.

AS> 1.  Leonardo raised an issue regarding the timing of when
AS> markInitialState() is called - ie. that markInitialState() needs to be
AS> called on the parent before the children - otherwise UIData won't be
AS> able to capture the full initial state of its children.  How did we
AS> solve this problem?  Are there spec changes relating to this?  Did we
AS> find a way to do this that doesn't require introducing yet another full
AS> tree traversal?

EB> I don't know.

LU> It is possible to prevent the full tree traversal, but to do that it
LU> is necessary to change all code that uses PostAddToViewEvent to
LU> relocate components, and that means refactor composite component
LU> solution as is. This was done on MyFaces, so there cc:insertChildren
LU> and cc:insertFacet does not use a Listener attached to that event
LU> there, but Mojarra uses it.

LU> Anyway, users could add components on PostAddToViewEvent to the tree, so
LU> in theory the call to markInitialState() should be done after that event is
LU> handled.

Again, I will not take action on this point raised by Andy.

AS> 3.  Are there cases where it might be useful to enable per-row
AS> transient state saving without also enabling non-transient state
AS> saving (which seems more expensive)?  I wonder whether it should be
AS> possible to enable these independently, in which case we may want to
AS> consider using an enum property instead of a boolean.  Also
AS> wondering whether transient row state saving should just be on by
AS> default or possibly always on.

EB> Leonardo?

LU> It is possible, but shouldn't that condition just depends on the
LU> component child itself ?.  For example, UIForm has submitted
LU> property that in the future will be stored in transient map, so this
LU> component requires transient state be always on.

Again, I will not take action on this point raised by Andy.

AS> While I agree that it would make sense for rowStatePreserved to be
AS> honored regardless of whether partial/full state saving is on,
AS> simply stating that:

EB> Note that this delta state is saved regardless of whether or not
EB> partial state saving has been enabled or disabled for this
EB> application.

AS> Is not nearly sufficient to cover the full state saving case.

I have removed that blithe statement and replaced it with this text, at
the very top of the setRowStatePreserved() javadoc, where the entire
feature is effectively specified.

"Note that because all of the actions related to this property are
conceptually related to the call to markInitialState, these actions are
not invoked for applications with partial state saving disabled.

AS> Part of the problem is that the spec for rowStatePreserved is overly
AS> detailed in what implementations are required to do.  The spec is
AS> very explicit about how to implement this feature for the partial
AS> state saving case, but this same approach does not work for the full
AS> state saving case.  We either need to describe both cases in detail,
AS> or revise the specification to provide a higher-level description of
AS> the expected behavior, rather than explicit implementation
AS> instructions.

Recall again the July Expert Community meeting.  At that meeting I said
something like, "We're really tight on resources, so we're only going to
do a few things.  If you want to submit some stuff, the door is open,
but you'll have to do the heavy lifting in providing the impl, spec, and
automated test content.  Leonardo contributed this entire feature;
the impl and automated test were spot on and worked well.  The spec
language was insufficient in my opinion so that's how we ended up with
what we have.

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, but we really need to do a better job of reigning in
such last minute scrambles.  

Ed

-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
|  4 work days until German Oracle User's Group Conference
| 11 work days until GlassFish 3.1 Hard Code Freeze