Any way to modify DSRequests generated by an editable ListGrid?

[jay.l.fisher]

I'm using a ListGrid that supports inline editing but I need to insert some logic at the point where the ListGrid is about to send a DSRequest to add or update a ListGridRecord. Specifically in this case I need to add a parameter to the DSRequest. I don't see any API that looks like the right one to use in this scenario. Is there a way to do this?

[Isomorphic]

You would generally use transformRequest() after setting a specific saveOperation on the ListGrid, that you can check for in transformRequest to trigger this special behavior.

[jay.l.fisher]

So I need to create a subclass of DataSource and override the transformRequest() method. But then how do I pass information to the transformRequest() method? Do I have to string everything together into one long operationID. That seems to be the only thing you can specify on the ListGrid.setUpdateOperation().

[Isomorphic]

Just set an updateOperation that acts as a kind of "flag" telling your code in transformRequest() that something extra needs to be done (eg, data needs to be added to the dsRequest). Note that the componentId is also available to you on the dsRequest - you could use this instead.

[jay.l.fisher]

In this case the data I need to pass can change from one request to the next. It is the currently selected value in a SelectItem that I need to include as an HttpParameter. It needs to be an HttpParameter so that it is accessible in the Velocity template context when the cache-synch fetch request is processed.

It seems like a very round about way to get something into the request. I either have to append it to the operation ID (which is already being used for other things) or to the ListGrid ID. Can I even change the ID on the ListGrid after it is created?

[Isomorphic]

What is the meaning of what's being attached to the request?

Is it data? Then use setEditValue().

Is it a hint about how the operation should be executed? Use the operationId. Yes, you can change it on the fly.

If it's something else then.. is it a hack? Maybe there's a simpler approach.

[jay.l.fisher]

The data source in this case returns summarized data and needs to support different summary levels. The user can choose the summary level via a SelectItem.

When I call fetchData() to load the grid I pass the requested summary level as an http param on the DSRequest. My server side code takes that and sets it as an attribute on the servlet request so it will be available in the Velocity context to use in constructing the appropriate GROUP BY clause in the operationBinding. The group level they choose also needs to be communicated on the add or update request so the, the cache-synch fetch can return the same summary level.

The grid also supports editing and the server needs to know the summary level of the record being edited so it can return the same summary level on the cache-synch fetch.

For an add request, in this case I don't need to let them add directly from the ListGrid. I have a set of forms they use for the add and there I can hang the group level they've chosen on the saveData() request when I send it.

I realize now that I can interrogate the update request on the server and determine the grouping level from the data itself. So my server side code can add the servlet request attribute in this case.

It just seems like a convoluted solution to a relatively simple requirement, as does the creation of a subclass of DataSource with transformRequest() overridden. That doesn't really change the fact that the only way of communicating anything to the DSRequest that eventually gets sent to the client is by appending something to the operation ID string or the component ID string.

It seems like the ListGrid API would benefit from something like addUpdateRequestHandler() or some other way to intercept the request and manipulate it before it goes to the server, and still have access to everything you need in the class that instantiates the ListGrid.

If there is an easier way to accomplish this I'm definitely open to it. I realize now that I've asked the same basic question in a different context, so thanks again for helping me step through the options. It just doesn't seem there is a simple way to do what I'm trying to do.

[Isomorphic]

Realize that the framework supports cross-component cache syncing, offline functionality, LRU caching and other advanced features related to data access. For this reason it's important that there's a simple and clear way to determine that two operations are the same kind of operation, other than their data. The operationId is used for this.

The ability to hang other, arbitrary data on requests sounds great until you realize that it makes it much more difficult to determine if two operations are equivalent.

So in this case we'd recommend just embedding the grouping level in the operationId.