Ticket #2081 (closed enhancement: duplicate)

Opened 2 years ago

Last modified 21 months ago

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

Reported by: guest Owned by: ttrenka
Priority: normal Milestone: 0.9
Component: Widgets Version: 0.4.1
Severity: normal Keywords:
Cc: seemann@…

Description

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

patch.patch (1.6 kB) - added by guest 2 years ago.
00-FilteringTable-r7337-fix.patch (1.4 kB) - added by aferber@… 21 months ago.
Fix for r7337

Change History

Changed 2 years ago by guest

Changed 23 months ago by ttrenka

  • owner changed from bill to ttrenka

Changed 22 months ago by dylan

  • version set to 0.4.1
  • milestone set to 0.9

Changed 22 months ago by ttrenka

  • status changed from new to closed
  • resolution set to fixed

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

Changed 21 months ago by ttrenka

  • status changed from closed to closed
  • resolution set to fixed

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

Changed 21 months ago by aferber@…

  • status changed from closed to reopened
  • resolution deleted

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.

Changed 21 months ago by aferber@…

Fix for r7337

Changed 21 months ago by ttrenka

  • status changed from reopened to closed
  • resolution set to duplicate

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

Note: See TracTickets for help on using tickets.