Re: dataTable row state saving / preserveRowStates / keying row states by row data

[Josué Alcalde González <jo...@gmail.com>]

Would not it work the attribute 'forceIdIndexFormula' ?
I use it to generate rows where the id in the dataTable is the same as
the real id in my database table.

El mié, 11-04-2007 a las 15:54 -0400, Mike Kienenberger escribió:
> I'm looking into the behavior of preserveRowStates in order to try to
> fix the issues with deleting a row when preserveRowStates=true.
> 
> One of the things I notice is that the key to the row state Map is the
> clientid of the dataTable, which of course varies based on the row
> index.  Is there some reason why the key isn't the row index?
> 
> What about the possibility of storing the row data in the map using a
> key based on the row data itself?   That way, changing the row model
> (adding/deleting rows) would automatically pick the right row state?
> The only issues are that we might be keeping the row state for rows
> that no longer in the model, and we might be holding onto a reference
> to an object that should be garbage collected (I've never delved into
> this, but my understanding is that there are ways around referencing
> things that should perhaps be garbage-collected).
> 
> However, if it works, it would automaticallly solve all of the row
> issues transparently to the end-user.  Sorting, inserting, deleting
> rows would work transparently.
> 
> We might also want to put in a preserveRowStatesConverter so we save a
> light-weight key to the row data rather than the row data itself like
> f:selectItems does.

Re: dataTable row state saving / preserveRowStates / keying row states by row data

[Mike Kienenberger <mk...@gmail.com>]

Josué, thanks for contributing.

Unfortunately, the problem we're hitting here doesn't have much to do
with the table id.   We're dealing with the problem of input
components in table rows losing their submitted values if an
immediate=true UICommand executes, especially if that action involves
changing the data model backing the dataTable.


On 4/11/07, Josué Alcalde González <jo...@gmail.com> wrote:
> Would not it work the attribute 'forceIdIndexFormula' ?
> I use it to generate rows where the id in the dataTable is the same as
> the real id in my database table.
>
> El mié, 11-04-2007 a las 15:54 -0400, Mike Kienenberger escribió:
> > I'm looking into the behavior of preserveRowStates in order to try to
> > fix the issues with deleting a row when preserveRowStates=true.
> >
> > One of the things I notice is that the key to the row state Map is the
> > clientid of the dataTable, which of course varies based on the row
> > index.  Is there some reason why the key isn't the row index?
> >
> > What about the possibility of storing the row data in the map using a
> > key based on the row data itself?   That way, changing the row model
> > (adding/deleting rows) would automatically pick the right row state?
> > The only issues are that we might be keeping the row state for rows
> > that no longer in the model, and we might be holding onto a reference
> > to an object that should be garbage collected (I've never delved into
> > this, but my understanding is that there are ways around referencing
> > things that should perhaps be garbage-collected).
> >
> > However, if it works, it would automaticallly solve all of the row
> > issues transparently to the end-user.  Sorting, inserting, deleting
> > rows would work transparently.
> >
> > We might also want to put in a preserveRowStatesConverter so we save a
> > light-weight key to the row data rather than the row data itself like
> > f:selectItems does.
>
>