Issue after saving edits for a ListGrid

[user316]

Hello,

I have a ListGrid and for various reasons I am mocking out the server-side code for executeUpdate. The server-side code returns a response containing the data, which is sent back to the client, which then needs to set the edits into the records as regular attributes. This is mostly working fine, and the grid appears to be taking in the edits, but when I then go to edit another row, the seemingly-saved edits in the original row then reset back to the way before.


Basically in my client-side code I am doing this:

                                grid.setEditValue(rowNum, displayField, strBuilder.substring(0,strBuilder.length()-1));
                                grid.setEditValue(rowNum, colNum, valBuilder.substring(0,valBuilder.length()-1));
                                grid.refreshRow(rowNum);
                                grid.invalidateCache();

                                if (saveChanges) {
                                    grid.saveAllEdits()


                                }

And in my server-side code (mocking out the update request to something custom)

public DSResponse updateChipSTAResponsibleEmails(DSRequest updateRequest) throws Exception {
        Map<String, String> dataItem = new HashMap(updateRequest.getValues());

        retlist.add(dataItem);

        resp.setData(retlist);
        resp.setAffectedRows(1);
        return resp;
}

I analyzed the DS responses and the data sent from the server to the client looks completely fine and there are no issues with that.


Any ideas why the grid behavior in the UI is not working 100%? As I mentioned the edits do appear to be saved (i.e. go from blue to gray), but if I afterwards edit any row, the "saved" edits then go back to the way before.

I did manage to create a workaround though by adding a callback to grid.saveAllEdits() and setting the attributes directly.

[Isomorphic]

It's not clear what you're expecting to happen here - you apply user edits then invalidateCache()? So that would drop the records to which the edits were applied.... ?

Also, calling saveAllEdits() immediately after invalidateCache() doesn't make sense, since there are edits floating there with no record cache to associate them with.

There isn't a specified behavior for this series of calls. We don't understand what you mean to achieve, but in general, you make the edits and you save them with saveAllEdits(), and the cache is updated automatically by the ResultSet's cache sync behavior (see ResultSet docs). You do not need to invalidateCache() and should not.

If you have some other reason to invalidateCache() in this flow (like perhaps other changes result on the server side, and for whatever reason you don't want to convey those to the client with DSResponse.addRelatedUpdates()), then you would do it *after* the save has completed.

Wiping out the cache in the middle of the save operation doesn't make sense, for multiple reasons, including what is expected to happen if validation errors are returned.

[user316]

Getting rid of invalidateCache() didn't fix the issue. The grid now won't even appear to save any of the edits after they come back, and I'm not sure why. After the update response, the blue edits in the grid change to gray, but the text reverts back to the way it was before there were any edits.

We don't understand what you mean to achieve

I'm trying to mock-out the server-side update call and return some data so that from the client grid's perspective, the record was successfully updated.

[Isomorphic]

All you have to do is return the record-as-saved, which is the standard DataSource protocol. Do not invalidateCache() or attempt anything like that, since that's going to definitely break things. You can see that cache update is achieved with normal (non-mock) responses so that tells you no manual steps are necessary.

If you enable the "ResultSet" log category, you can see how the ResultSet is treating your returned data. The most common problems here are:

1. not returning a PK or somehow returning the wrong PK, so there's no way to match with client-cache records

2. returning partial data instead of the whole record