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(a)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