Opened 15 years ago

Closed 15 years ago

#2081 closed enhancement (duplicate)

FilteringTable: onAddData fires also if the data in the store are replaced

Reported by: guest Owned by: Tom Trenka
Priority: high Milestone: 0.9
Component: Widgets Version: 0.4.1
Keywords: Cc: [email protected]
Blocked By: Blocking:


If the data in the store are replaced with a new objekt (but the same key) the event onAddData will fire - that's ok. The FilteringTable?-Widget should be aware of this. Attached is a patch that solved the problem in this special case.

Attachments (2)

patch.patch (1.6 KB) - added by guest 15 years ago.
00-FilteringTable-r7337-fix.patch (1.4 KB) - added by [email protected] 15 years ago.
Fix for r7337

Download all attachments as: .zip

Change History (8)

Changed 15 years ago by guest

Attachment: patch.patch added

comment:1 Changed 15 years ago by Tom Trenka

Owner: changed from bill to Tom Trenka

comment:2 Changed 15 years ago by dylan

Milestone: 0.9
Version: 0.4.1

comment:3 Changed 15 years ago by Tom Trenka

Resolution: fixed
Status: newclosed

(In [7319]) Fixes #2081 by creating new events on the Store and adding new handlers on the FilteringTable? widget.

comment:4 Changed 15 years ago by Tom Trenka

Resolution: fixed

(In [7337]) Ok. FINALLY fixes #2081. Object comparison for getting the correct row to be swapped was wrong.

comment:5 Changed 15 years ago by [email protected]

Resolution: fixed
Status: closedreopened

It is still broken, at least in FireFox? 2.x. Note that dojo.collections.Store.onUpdateData takes the Store entry as a parameter, which has the stored data available as .src property, however getRow() in FilteringTable? compares the real data object.

For performance (and easier to understand code IMHO) it might be the best to compare the row key value against the key directly, instead of going the indirect way by comparing data objects.

I'm going to attach a patch (against r7337) that fixes the problem for me and changes to comparing keys directly. There are some other places that also might be switched to the new getRowByKey method, however I'm leaving them alone for now and only fix the bug at hand.

comment:6 Changed 15 years ago by Tom Trenka

Resolution: duplicate
Status: reopenedclosed

Your reopening is a dupe of #2469. Closing in favor of that.

Note: See TracTickets for help on using tickets.