myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: dataTable row state saving / preserveRowStates / keying row states by row data
Date Thu, 12 Apr 2007 01:54:58 GMT
Well, this is kinda odd.

I've implemented the converter version, and it *almost* works.

Without the converter, using the standard clientId key,

		public String getAsString(FacesContext context, UIComponent
component, Object value)
		{
			UIData uiData = (UIData)component;
			return uiData.getClientId(context);
		}

If you have

row 1 - 1111
row 2 - 2222
row 3 - 3333
row 4 - 4444
row 5 - 5555

and you delete row 2, you get:

row 1 - 1111
row 3 - 2222
row 4 - 3333
row 5 - 4444

Now if I throw in a converter that maps to an object:

        public String getAsString(FacesContext context, UIComponent
component, Object value)
        {
            UIData uiData = (UIData)component;
            if (uiData.isRowAvailable())
            {
                Item item = (Item)uiData.getRowData();
                return "Item" + String.valueOf(item.getId());
            }
            return uiData.getClientId(context);
        }

If you have

row 1 - 1111
row 2 - 2222
row 3 - 3333
row 4 - 4444
row 5 - 5555

and you delete row 2, you get:

row 1 - 1111
row 3 - 2222
row 4 - 4444
row 5 - 5555

Weird.   Everything is correct except for row 3 (which picked up the
values for row 2), which is a vast improvement over the original, but
still not quite right.


On 4/11/07, Mike Kienenberger <mkienenb@gmail.com> wrote:
> I don't think this will affect the nested datatables since we're not
> changing the value, only the key, for each row-state map entry.
> However, I might be misunderstanding something.
>
> A starting point could be
>
>     private Map _rowStates = new WeakHashMap();
>
> Then, we'd change this:
>
>             _rowStates.put(getClientId(facesContext),
>                             saveDescendantComponentStates(getChildren()
>                                             .iterator(), false));
>
> to
>
>             _rowStates.put(dataModel.getRowData(),
>                             saveDescendantComponentStates(getChildren()
>                                             .iterator(), false));
>
> Note, for describing this, I'm ignoring how we'd handle isRowAvailable=false.
> I'm guessing this would require that rowData be serializable.
>
> A better implementation might be:
>
>             Converter converter = .... [either assigned explicitly or
> fetched by RowData type]
>
>             _rowStates.put(converter.getAsString(dataModel.getRowData()),
>                             saveDescendantComponentStates(getChildren()
>                                             .iterator(), false));
>
> Now we're no longer storing a weak reference to the model object
> (good), but we'll now have to be responsible for keeping the
> _rowStates map cleaned up (bad).   Now we won't have serialization
> issues (good).
>
> One potential snag might be if the backing data model contains
> identical objects.  I can't think of a practical use case for this
> (inputs on multiple rows for the same object), but that doesn't mean
> that there isn't one.
>
>
>
> On 4/11/07, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > Your ideas sound good, one thing that I remember was discussed while
> > implementing preserveRowStates - there were some problems with nested
> > data-tables - you'd need to work around those problems specifically.
> >
> > What would be your idea of a key based on the row-data?
> >
> > regards,
> >
> > Martin
> >
> > On 4/11/07, Mike Kienenberger <mkienenb@gmail.com> wrote:
> > > 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.
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>

Mime
View raw message