Questions regarding sending custom parameter in removeData operation

[mathias]

SmartGWT pro 6.0/6.1

I am trying to send a parameter along with a delete operation on a DataSource. It's a user comment for reason for deleting, so i do not want it to be a part of the datasource.

I am a little bit puzzled as to how parameters are sent in the delete dsrequest

DSRequest req = new DSRequest();
ds.removeData(record, new MyCallback() {
    @Override
    public void doExecute(ResponseData rData, DSResponse dsResponse, Object o, DSRequest dsRequest) {
        //do stuff
    }
}, req);

1. If i use "setParams" on the req above, i can then get at the parameter on the server:

LinkedHashMap<String, String> params = new LinkedHashMap<String, String>();      
params.put("text", theText);
req.setParams(params);

But, DSRequest.getparameter("text") does not work on the server, as one might expect. Only if i do DSRequest.getContext().request.getParameter("text") can i get at it.

2. I tried setCriteria, and this is pretty confusing to me:

--I get the "id" field on the server by DSRequest.getFieldValue("id"), but when i debug, i see that it actually comes in through "clientSuppliedCriteria".

So, it turns out that if i do
req.setCriteria(new Criteria("text", theText));
in the client code above, my dsRequest.getFieldValue("id") call on the server now returns null!

To me, it seems strange that manually setting the criteria for the dsrequest on a DataSource.removeData call. After all, the method takes the record as a parameter. I can of course also set the "id"
as an additional parameter when i set the criteria, but why would i then need to send in the actual record?


So, my questions are:

1. Am i missing something regarding the DSRequest.getContext().request.getParameter()? Don't you think that the API would make more sense if i could get the parameter directly in DSRequest.getParameter()?

2. is setting the criteria manually making the "id" disappear expected behaviour?

3. to send a custom parameter in the removeData request, is my only option setParams?

4. Don't you agree that it's a bit confusing that setting the criteria causes getFieldValue to suddenly become null. It's not really logical to me, nor is it documented?


Thoughts much appreciated! :)

[Isomorphic]

1. dsRequest.getParameter() is not a documented API and you should not be calling it. It is not used for HTTP parameters.

2 & 4. setting the criteria sets the whole criteria, so yes, this is expected and correct behavior. If this were not the case you could not actually fully control the criteria

3. no, we would recommend declaring it as a DataSource field and simply marking it not persistent and hidden. You are expecting it to be serialized/deserialized rather than discarded, and have the correct type, etc, so a field definition is appropriate.

[Blama]

Hi mathias,

I assumed that this would be the answer. See here, were I have a similar case. I now use a field with customSelectExpression="null" and comment it in .ds.xml, why I have it.

Best regards
Blama

[mathias]

My main problem in this instance is that the "reason" in this case is NOT a datasource field, i would argue. It does not go into the table in question, nor is it part of the domain object. It's something we put in an auditlog. It really is a special field IMO, that i would like to send along, but separately.

I really wish there would be some way to pass it along some other way.

Thanks for clarifying, guys.

[Isomorphic]

Sorry, you are simply incorrect as to the definition of a DataSourceField. Defining a persistent field is the most common use case, but in general fields describe data values that may be used as criteria and for other purposes as well.

[mathias]

Correct, incorrect... OK, let's say it's the way i, as a user, think usage of DataSourceField makes most sense. To me, it's confusing to define a "deleteNote" datasourcefield in my User.ds.xml, since it has nothing to do with a user.

But that's just me. Again, thanks for clarifying.

[Isomorphic]

Your parameter affects the behavior of an operation on the User DataSource. That's why it's definition belongs in the DataSource.

If it was related strictly to HTTP transport it would make sense as an HTTP parameter. We for instance tell our server whether we're using xmlHttpRequest or another transport this way.

Also realize that for non-string values, we would need to know the type to serialize it correctly (especially e.g. distinctions between date, datetime and time). Several other settings on DataSourceField also apply to closely related use cases.

We could invent another type of cofiguration, very very similar to DataSourceField but placed elsewhere, but it should be clear that doesn't make much sense.