Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#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:


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.

Attachments (1)

base-grid-sort-defect.png (21.8 KB) - added by David Schwartz 13 years ago.
the type was changed to country yet Europe remains in its original location

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by David Schwartz

Attachment: base-grid-sort-defect.png added

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

comment:1 Changed 13 years ago by David Schwartz

Steps to reproduce the issue: 1. Open 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:2 Changed 13 years ago by David Schwartz

Is this getting fixed for 1.4?

comment:3 Changed 13 years ago by 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. :)

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by Adam Peller

Keywords: 14open added; oci ibm grid removed

moving 1.4 open tickets to 1.5

comment:6 Changed 12 years ago by bill

Milestone: 1.51.6

1.5 is released, moving remaining tickets to 1.6

comment:7 Changed 11 years ago by bill

Milestone: 1.6future

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

comment:8 Changed 11 years ago by Bryan Forbes

Resolution: invalid
Status: newclosed

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 store. As a result, we are constrained by the limitations of Since 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 11 years ago by bill

Kris mentioned that it's possible to support this with the new 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 11 years ago by 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.

Note: See TracTickets for help on using tickets.