Set operationId on listgrid multiple times not working?

[claudiobosticco]

v13.1p_2025-04-06/Enterprise Deployment

Hello, may I ask if you think there might be a problem here? I keep seeing this error in my code.

[claudiobosticco]

SmartClient Version: v13.1p_2025-01-31/Enterprise Deployment (built 2025-01-31)

Hello, I've got an error in my code which I think it's related to this change:

We've reviewed this behavior and have added logic to listGrid.setFetchOperation() to drop the current filtered data set if there is one.

I was setting the fetchOperation on a TreeGrid, with separateFolders:true, and now I get an error:

22:37:08.620:WARN:Log:TypeError: newData.setSeparateFolders is not a function
Stack from error.stack:
    setData() @ isomorphic/system/modules-debug/ISC_Grids.js?isc_version=13.1-p20250131.js:82328:51
    setFetchOperation() @ isomorphic/system/modules-debug/ISC_Grids.js?isc_version=13.1-p20250131.js:33921:14
    setProperties() @ isomorphic/system/modules-debug/ISC_Core.js?isc_version=13.1-p20250131.js:9388:29
    setProperty() @ isomorphic/system/modules-debug/ISC_Core.js?isc_version=13.1-p20250131.js:9336:14

[mathias]

hey there, sounds great. Makes it more in line with what you'd expect from the functionality IMO. Cheers

[Isomorphic]

Hi Mathias and Blama
We've reviewed this behavior and have added logic to listGrid.setFetchOperation() to drop the current filtered data set if there is one.
It will not re-filter automatically - if application code wants a fresh fetch they will issue one after changing the fetch operation Id.

This change has been applied to branches 13.1 and above. We will not be back-porting to older branches - instead you can continue to manually call setData() and pass in an empty array and then issue a fetch request.

Developers should also be aware that there may be some edge cases where changing the fetch operation and refetching on the fly doesn't match user expectations. For example if an operationBinding only fetches a subset of the available fields (EG via operationBinding.outputs), the grid may have blank cells, etc.

In cases where the setFetchOperation() behavior isn't sufficient to get the view you need, we'd recommend simply creating a new grid.

Regards
Isomorphic Software

[Isomorphic]

Hi Mathias

We see the behavior you are describing

We'll take a look at this case, but for now you can get past this by explicitly clearing out the data object and re-fetching instead of relying on invalidateCache() after setting the operation ID.
This can be achieved with a 'setData(...)' call, passing in an empty list, then calling 'fetchData()' to re-fetch with the new fetchOperation

Regards
Isomorphic Software

[mathias]

Doesn't matter, once you set it, the grid will use that operationId in requests forever, from what I can tell.

private void handleOperationId(boolean setEnabled){
        String newOpId = setEnabled ? operationId : "fetch";
        GWT.log("handleOperationId: " + operationId + ", setEnabled: " + setEnabled +  ", setting operation to: " + newOpId);
        grid.setFetchOperation(newOpId);
    }

If you set it to fetch or anything else first, it will always have that, and the other way around.

[Blama]

Hi mathias,

what happens with

grid.setFetchOperation(setEnabled ? operationId : "fetch")

?

Best regards
Blama

[mathias]

Hello,

just tried this on a list grid:

private void handleOperationId(boolean setEnabled){
        GWT.log("handleOperationId: " + operationId + ", setEnabled: " + setEnabled);
        grid.setFetchOperation(setEnabled ? operationId : null);
    }

But it seems that after you set it once, it doesn't change? After my method above, I do invalidateCache, and it still uses the old operation when fetching.