2010/8/25 Ed Burns <edward.burns@oracle.com>

>>>>> On Wed, 25 Aug 2010 13:52:46 -0700, Ed Burns <edward.burns@oracle.com> said:

>>>>> On Tue, 17 Aug 2010 16:02:01 -0500, Leonardo Uribe <lu4242@gmail.com> said:
LU> Hi
LU> 2010/8/13 Ed Burns <edward.burns@oracle.com>

EB> Here is my response.

LU> Note by default this feature is not active, so I think to test it fully it
LU> is necessary to activate it setting
LU> preserveRowComponentState to true.

EB> I have executed your very excellent testcase app. When I traverse the
EB> app with the markInitialState variant of your fix in place, the fields
EB> are red that should be red. When I remove the fix and re-traverse the
EB> app, all of the fields are red.

EB> I'm experimenting with having preserveRowComponentState to true by
EB> default. What do you think of that?

Well, that didn't work so well. As you'd expect, this failed pretty
quickly because we had an existing test that exercised the existing
behavior.

Is everyone OK with having this be configured as a UIData property, or
would it be better done using a context-param?

The problem with allow it with a context-param is there is no way to "reset" the deltas
or remove rows to synchronize the model with the component state.

Suppose a simple use case, where there is a datatable and an option that removes one
row. Since we don't have a way to notify the component that the row has been removed
the state of the deleted row will be applied on the next one.

It is worth to mention that tomahawk HtmlDataTableHack has a method to deal with this
specific use case called:

public void deleteRowStateForRow(int deletedIndex)

Maybe it is not the best solution but works. In theory, a publisher-suscriber pattern could
do the job better in this case.