Re-ordering records in a ListGrid

I have a ListGrid that is associated with a client-only data source. The user can select a record in the grid. I want to have a toolbar button to move the selected record up or down one record. However, I have not been able to find a way programmatically to move the record in the grid (the grid is not sorted).

Can you point me to how to do this?

I've tried calling getOriginalResultSet() and then using a combination of removeAt() and addAt() to move the record, but that had no visual effect on the grid.

[Isomorphic]

When working with a DataSource, the only meaningful way to change order of records is to have a field that tracks the order, sort by that field, and modify that field when the user reorders records. This is demonstrated here.

If this isn't really a true DataSource situation (specifically: you are not really trying to provide an editable view onto a remote dataset), then you can just provide data as a RecordList, in which case you can directly modify it with APIs like addAt / removeAt. This is shown here.

I tried doing code almost exactly like the one in your second reference since there is no connection to a remote dataset. However, getRecordList() is returning null (as does getResultSet(), but getOriginalResultSet() does return my record set). I assume that this is because instead of just calling setData and addData on my grid, I am actually setting up a client-only data source and setting the data source on the grid. Is that correct? If so, I assume my only reasonable option then is having something like a hidden order column as you describe in option 1, right?

[Isomorphic]

If this isn't really a true DataSource situation (specifically: you are not really trying to provide an editable view onto a remote dataset), then you can just provide data as a RecordList, in which case you can directly modify it with APIs like addAt / removeAt. This is shown here.

So again, if you are not trying to provide an editable view onto a remote dataset, you can just provide the data as a RecordList via setData().

Other than calling getRecordList() before data is loaded, we're not sure how you could get it to return null, but it doesn't matter anyway if you are actually passing in a RecordList as the dataset - you already have it in that case.

I am creating a DataSource and initializing it with:

setClientOnly(true);
setCacheData(new Record[] {});

I am then setting the data source on the grid and over time records are added by calling ListGrid.addData(Record, DSCallback).

When I do this, I get the behavior I described previously - getRecordList() and getResultSet() return null, but getOriginalResultSet() returns is not null and contains the list of records that have been added.

I realize that I could do this without an explicit DataSource. However, I have found other differences (besides the one described above) where using an actual DataSource for a grid and not using one behave differently. We are trying to normalize our code with common support routines for our grids. So we normalized on using a DataSource for all of our grids as the common ground.

[Isomorphic]

OK, please note we keep saying this:

If this isn't really a true DataSource situation (specifically: you are not really trying to provide an editable view onto a remote dataset) ..

By using a DataSource you are specifically telling the system that you are dealing with a remote dataset. This implies all kinds of things, like all operations having to be asynchronous and things like reordering becoming a complicated problem instead of a simple call performed analogously to how you'd do it with java.util.List.

For this reason components like ListGrid support working with a RecordList -a much simpler mode, with synchronous changes allowed.

So when you say:

We are trying to normalize our code with common support routines for our grids. So we normalized on using a DataSource for all of our grids as the common ground.

This basically means you are signing up to handle all the complexity necessary when working with a remote dataset, even when the dataset is local, and this is something we'd consider a really bad idea.

Finally, again it would not be expected for getRecordList() to return null if you are databound and have fetched data, so if you could can produce a test case showing that behavior, please let us know. But note that this doesn't bear on your use case anyway - you need to provide a RecordList via setData(), or you are still dealing with a ResultSet, which by design does not allow direct, synchronous changes to records.

Thank you. This description was really valuable. I think we have made the wrong choice normalizing on having a DataSource and we're going to restructure to only use a DataSource when dealing with remote data. I think that will clear up a lot of the issues we've been running into.