Hi I attached a patch with better documentation for TransientStateHelper - TransientStateHolder and the answers requested. If you need anything else just let me know and I'll do it. I resume the comments below: EB> Leonardo, why is the preceding state traversal saved into EB> this funky two element array, whereas the next one, described EB> below, saved into the normal Map? It is necessary to save the "initial rolled up state" in a way that the state could be restored without depend of the row where the component or the model is, so an implementation option could be use an array like structure, so traversing it could restore the state. Since the row index is attached to the client id of child components, use a Map in this case will work on simple datatables but will not work on nested datatables correctly. EB>Traverse the children as done with markInitialState, saving the EB>state of each child. Because the saveState calls during this pass EB>happen after the call to markInitialState, the state saved is the EB>so called "delta" state of each component. Because this EB>traversal happens during a per-row operation (in this case, EB>setRowIndex) the rolled up state must be saved in a row-aware EB>data structure. One implementation choice would be to save EB>the state from this pass in a Map keyed by the return from EB>javax.faces.component.UIComponent#getContainerClientId. The algorithm uses as key is call child.getClientId() that calls UIData.getContainerClientId() later, but other alternative could be use child.getClientId() but trim the value from UIData.getContainerClientId(). That makes easier fix the problem when a row is deleted. EB> Why do we need to bother passing null to EB> restoreTransientState()? There must be a good reason, but I need EB> to include it in the specification.</p> It is necessary to pass null to restoreTransientState() to indicate the transient state should discarded from the previous one, otherwise the transient state could be shared between rows. To include the patch in jsf 2.1, we need to resolve the following point left: - On UIData.markInitialState do not use a facesContext attribute "com.sun.faces.MARK_INITIAL_STATE", instead it could be better to use a variable on FacesContext to indicate when we are marking the initial state, like FacesContext.isProcessingEvents() works. It could be event better to add flags to indicate when the current view is being built using pss and when the view is being refreshed. It comes in handy in some situations, but that's another issue (and I'm not found yet strong arguments to support this more than myfaces PSS solution uses it in multiple places). best regards, Leonardo 2010/8/26 Martin Marinschek <mmarinschek(a)apache.org&gt;