ListGrid.refreshData() doesn't trigger dataArrived notification

[claudiobosticco]

SmartClient Version: SNAPSHOT_v11.1d_2016-09-22/Enterprise Deployment (built 2016-09-22)

Chrome on OSX El Capitan

Hell, I've just noticed that ListGrid.refreshData() doesn't trigger the dataArrived notification.

Is it a bug, or by design?

Test case:

isc.IButton.create({
    ID:"refreshButton",
    title:"Refresh Data",
    click:"dsListGrid.refreshData()"
})

isc.ListGrid.create({
    ID:"dsListGrid", 
    top:30,
    width: "100%",
    height: "100%",
    minFieldWidth:80,
    autoFetchData: true,
    dataSource: "supplyItem",
    dataArrived:function(startRow, endRow) {
        isc.logEcho("dataArrived")
    } 
});

[claudiobosticco]

besides, it doesn't trigger transformData on the grid's ResultSet

isc.IButton.create({
    ID:"refreshButton",
    title:"Refresh Data",
    click:"dsListGrid.refreshData()"
})

isc.ListGrid.create({
    ID:"dsListGrid", 
    top:30,
    width: "100%",
    height: "100%",
    minFieldWidth:80,
    autoFetchData: true,
    dataSource: "supplyItem",
    dataArrived:function(startRow, endRow) {
        isc.logEcho("dataArrived")
    },
    dataProperties: {
        transformData: function (newData, dsResponse) {
            isc.logEcho('transformData')
        }
    } 
});

instead, invalidateCache triggers both.

[Isomorphic]

Neither notification fires, since the underlying ResultSet actually gets replaced. If you need a notification of completion of the refresh, you can pass a callback to refreshData().

[claudiobosticco]

Thanks, so...isn't there a way to modify the data returned after a refresh, before the ResultSet gets replaced?

[Isomorphic]

Yes, DataSource.transformResponse(). If it should only happen for a certain component, you can use a special operationId via listGrid.fetchOperation.

[claudiobosticco]

Thanks for the suggestion.

I need it to set ListGridRecord.singleCellValue for some records.
But I need a slightly different behavior for different grids.
Is it supported to test for dsRequest.componentId inside transformResponse?
Otherwise I'll have to use different operationIds, but I don't really like it because it's only a different presentation logic, not a difference in server side behavior.

[Isomorphic]

It's never valid to set dsRequest.componentId, it's doc'd as read-only. So operationId is the way to go if for some reason you need different data on refresh of different grids.

[claudiobosticco]

Ok, but I did not intend to set dsRequest.componentId. I intend to read it in transformResponse to distinguish which grid has issued the dsRequest. Is it a valid usage or I must rely only on operationId?

[Isomorphic]

Reading it is fine, just bear in mind, when two components are using separate operationIds they are assumed to have distinct caches: updates performed with one operationId will not affect the cache obtained via another operationId. With two different componentIds, this is not the cache: any changes will update all caches.

[claudiobosticco]

Fine, thank you very much for the clarification.

[Blama]

Hi Isomorphic,

could you explain how ResultSet caching / application to DataBoundComponents is done? Your last posts makes me wonder a bit.

Until now, I (not the OP) thought that there is only one cache per DataSource, e.g.

1. LG1: fetch operationId1 (with some criteria on the server) -> Result 1
2. LG2: fetch operationId2 (with some other criteria on the server) -> Result 2
3. Update in one ListGrid -> Response will be incorporated in both ListGrids, no matter what

Is there some way to stop this behavior, perhaps by having

• operationBinding: type="fetch" operationId="op1"
• operationBinding: type="update" operationId="op1" (same operationId as for fetch above)
• operationBinding: type="fetch" operationId="op2"
• operationBinding: type="update" operationId="op2" (same operationId as for fetch above)

resulting in DSResponses from update:op1 only affecting ListGrids with current data for fetch:db1 and
DSResponses from update:op2 only affecting ListGrids with current data for fetch:db2?

Further: Should an operationId be unique per DataSource or per DataSource+Type?
Which docs cover this best?

Thank you & Best regards
Blama

[Isomorphic]

Cache sync is based on the fetch used - any add or update operation uses a fetch to retrieve updated data, which can be set via operationBinding.cacheSyncOperation. If the operationId of the cache is different from the operationId of the cache update data, it won't be used to update the cache, since the fields included and other aspects of the data are allowed to be different across different operationIds.

[Isomorphic]

Oh, and operationId must be unique per DataSource, across all operationTypes for that DataSource.

[Blama]

Hi Isomorphic,

all the information I needed, thank you.
Perhaps this is something for the CacheSync-docs. Or is it already documented somewhere?

Best regards
Blama

[Isomorphic]

You can find the documentation regarding cache synchronization under the "Updates and Automatic Cache Synchronization" section of the ResultSet class overview, where we have elaborated further about operationId based on this post's discussion. You'll find it updated in tomorrow's nightly build.