Currently when an AppGrid has an associated row page (opened via double-click), changes made on the row page do not automatically show back in the grid (unless/until it is refreshed). The reason for this is that the row page has an entirely separate Ext.data.Store from that of the grid, which is necessary to support a different (typically larger) set of active/loaded columns from that of the grid's store.
Previously this was addressed by automatically triggering a refresh of the grid's store whenever the page store saved changes, but this was not a good solution due to performance, especially if the active grid query is expensive, and so that code has been disabled.
Tied store design
Although the stores are separate and need to stay separate, a good solution may be to add custom code to be able to "tie" separate stores together. This would involve writing code to hook into write events and introspect the tied store to be able to identify matching records to the local store that have changed and directly update/sync the appropriate columns.
As long as this is an optional mode and certain assumptions can be made related to common column names, this shouldn't actually be all that complicated to write. It may simply be able to just update the overlapping field names as long as at least the id fields match.
The benefit of this design will be that it will be purely client side and work instantly
Background
Currently when an AppGrid has an associated row page (opened via double-click), changes made on the row page do not automatically show back in the grid (unless/until it is refreshed). The reason for this is that the row page has an entirely separate Ext.data.Store from that of the grid, which is necessary to support a different (typically larger) set of active/loaded columns from that of the grid's store.
Previously this was addressed by automatically triggering a refresh of the grid's store whenever the page store saved changes, but this was not a good solution due to performance, especially if the active grid query is expensive, and so that code has been disabled.
Tied store design
Although the stores are separate and need to stay separate, a good solution may be to add custom code to be able to "tie" separate stores together. This would involve writing code to hook into
writeevents and introspect the tied store to be able to identify matching records to the local store that have changed and directly update/sync the appropriate columns.As long as this is an optional mode and certain assumptions can be made related to common column names, this shouldn't actually be all that complicated to write. It may simply be able to just update the overlapping field names as long as at least the id fields match.
The benefit of this design will be that it will be purely client side and work instantly