#9876 closed defect (invalid)
Grid sort should persist across the life of the grid instance
Reported by: | David Schwartz | Owned by: | Bryan Forbes |
---|---|---|---|
Priority: | high | Milestone: | future |
Component: | DojoX Grid | Version: | 1.3.2 |
Keywords: | 14open | Cc: | |
Blocked By: | Blocking: |
Description
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
Attachments (1)
Change History (11)
Changed 11 years ago by
Attachment: | base-grid-sort-defect.png added |
---|
comment:1 Changed 11 years ago by
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.
comment:3 Changed 11 years ago by
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. :)
comment:4 Changed 11 years ago by
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.
comment:5 Changed 11 years ago by
Keywords: | 14open added; oci ibm grid removed |
---|
moving 1.4 open tickets to 1.5
comment:6 Changed 11 years ago by
Milestone: | 1.5 → 1.6 |
---|
1.5 is released, moving remaining tickets to 1.6
comment:7 Changed 10 years ago by
Milestone: | 1.6 → future |
---|
(sadly) punting seemingly abandoned ticket and meta tickets to future
comment:8 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
comment:9 Changed 10 years ago by
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).
comment:10 Changed 10 years ago by
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.
the type was changed to country yet Europe remains in its original location