Grid sort should persist across the life of the grid instance

[David Schwartz]

Sorting a grid affects the property of the grid *view* from the user's perspective. Accordingly, the data should remain sorted throughout the life of the grid instance or until the user explicitly changes it (as in when they re-sort, remove the sort or move rows around like they can in the EnhancedDataGrid?).

When a cell's value is changed in a sorted column, the sort should update to reflect the new value since the view property 'sort' is still in place from the user's perspective.

​http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/grid/tests/test_data_grid_edit.html

[David Schwartz]

the type was changed to country yet Europe remains in its original location

[David Schwartz]

Steps to reproduce the issue: 1. Open ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/grid/tests/test_edit_dijit.html 2. Sort column "Priority", now column "Priority" is in ascending sequence. 3. Double click the 4th cell in column "Priority", and change the content to anything like "note" 4. The column "Priority" is still in ascending sorting, but in face it is not any more.

[David Schwartz]

Is this getting fixed for 1.4?

[Nathan Toone]

I'm guessing this is not going in for 1.4...

BTW - I noticed today that windows explorer doesn't do this either (at least on Windows XP)...for example, if you are viewing a directory, in "List" view, and sort by file name, then change the name of one file, they are not resorted (even though the sort indicator still shows that they are).

Just an observation that I made earlier today...not that it changes whether or not this bug is valid...but we aren't the *only* ones that aren't doing it. :)

[gabehamilton]

I think the present behavior, not re-sorting after an edit, is preferable. I would say that most users do not expect the data to re-sort and many will be upset that the row they are editing has "disappeared" after they edit one column but before they can edit a second column.

For those developers who do want the grid to resort after an edit, a call to sort can be made at the end of the onApplyCellEdit event handler.

I recommend closing this ticket.

[Adam Peller]

moving 1.4 open tickets to 1.5

[bill]

1.5 is released, moving remaining tickets to 1.6

[bill]

(sadly) punting seemingly abandoned ticket and meta tickets to future

[Bryan Forbes]

I agree that the present behavior is preferable for one big reason: The grid is only a view of the data behind it. In the case of DataGrid?, this means it's a view of a dojo.data store. As a result, we are constrained by the limitations of dojo.data. Since dojo.data doesn't provide a way to find what "page" of data a record is in, there would be no way to follow the row as it's being edited. If you are editing a row that has several values that are editable and you tab to a sorted column, change it, and then tab to the next column, the grid would have to save the value to the store (because who is to know if this is a client-side-only store or one proxying a server), and request the whole set of sorted data so it could find the record it was editing. This is sub-optimal and the reason for the current behavior.

[bill]

Kris mentioned that it's possible to support this with the new dojo.store API. I don't think we should though, as per Gabe's comments above. Perhaps the column header should change to indicate that the grid is no longer sorted (ie, there shouldn't be an arrow symbol next to the column name).

[David Schwartz]

Removing the sort would be fine by me. It would remove the affected column from the sort and the indices for the 'downstream' columns in the sort would update. I actually think this is better as it's less disruptive for the user.