Issues in SmartGWT 2.4 migration

[tgallage]

This is my current application environment :
1) Java 1.6, Smart GWT 2.2, GWT 2.0.3
2) All data sources are JSON RestDataSources.

We tried to upgrade above to SmartGwt 2.4 and GWT 2.2. I downloaded the SmartGwt 2.4 last release and updated the smartgwt.jar, msartgwt-skins.jar, gwt-servlet.jar libraries.

But We found a major issue in single DateItem fields in Dynamic/Search forms, started to appear as double Date range fields. This is really strange as we set them as DateItem fields.

Please give us a feedback asap.

[Isomorphic]

This was found and fixed about 2 weeks ago. Can you test your upgrade against a nightly until the next release?

[tgallage]

We tried the nightly build of April 05, 2011. Now the above issue seemed to be fixed. But it is very strange as sort of new issue has arisen.

Our System shows error messages in a Panel when server returns an error or validation failure. So it has been working fine.
But after the migration now it always popup a Warn message with "Server returned VALIDATION_ERROR with no error message" which is very troublesome for the user.

[Isomorphic]

Can you show a sample of a response from the RPC tab in the Developer Console where this is the result?

[tgallage]

Following are the RPC tab traces in developer console.

RPCRequest
=======
{
"actionURL":"costRequestSupport!fetchCostRequestList.action",
"showPrompt":false,
"prompt":"Finding Records that match your criteria...",
"transport":"xmlHttpRequest",
"useSimpleHttp":true,
"promptStyle":"dialog",
"params":{
"_operationType":"fetch",
"_operationId":"",
"_startRow":0,
"_endRow":75,
"_sortBy":"costingRatePrivate",
"shipDate":"2011-04-07T18:27:29"
},
"httpMethod":"GET",
"sendNoQueue":true,
"bypassCache":true,
"callback":{
"target":[RestDataSource ID:isc_CostRequestDS_0]
},
"willHandleError":true,
"serverOutputAsString":true,
"clientContext":{
"requestIndex":3,
"$69t":null
},
"data":null
}

DSRequest
=======

{
"dataSource":"isc_CostRequestDS_0",
"operationType":"fetch",
"componentId":"isc_CostRequestViewPanel_16_0",
"data":{
"shipDate":"2011-04-07T18:27:29"
},
"startRow":0,
"endRow":75,
"sortBy":[
"costingRatePrivate"
],
"textMatchStyle":"exact",
"resultSet":[ResultSet ID:isc_ResultSet_33 (created by: isc_CostRequestViewPanel_16_0)],
"callback":{
"caller":[ResultSet ID:isc_ResultSet_33 (created by: isc_CostRequestViewPanel_16_0)],
"methodName":"fetchRemoteDataReply"
},
"willHandleError":true,
"showPrompt":false,
"prompt":"Finding Records that match your criteria...",
"clientContext":{
"requestIndex":3
},
"requestId":"isc_CostRequestDS_0$62739"
}

Response
======

{"model":{"shipDate":"2011-04-07T23:57:29"},"responseErrors":{"":"Select either Origin or Destination"}}

[Isomorphic]

OK, that response is invalid for a normal RestDataSource: no status field, validation errors in wrong format, etc: see the RestDataSource docs to see how to form a valid response.

[tgallage]

Do we need to have 'status' ?
What do you mean by 'responseErrors' is incorrect ?
Following is a response which is valid & working fine in system. There you can see we don't have 'status'.

{"list":[{"address":"USA","carrierName":"DANCO LTD","carrierOrgId":971253,"contactName":"DANCO LTD","email":"SUPUN@TEST.COM","fleetSize":0,"hazmatCertified":"N","id":15,"paymentType":"POD","rowActive":"Y","rowCreateUserFullName":" ","rowUpdateDate":"2011-04-08T00:00:00","rowUpdateUser":"chamalsx","rowUpdateUserFullName":"Chamal Pathirana of SHIPXPRESS","sxpCarrierCode":"DANCOL"}],"model":{"carrierName":"DANCO LTD","hazmatCertified":"N","rowActive":"Y"},"responseEndRow":1,"responseErrors":{},"responseStartRow":0,"responseTotalRows":1}

[Isomorphic]

That response bears no resemblance to the default format used by the RestDataSource, so if that response is working you must have heavily customized RestDataSource. So, look at the DSResponse object your code produces - the error message suggests that you've set dsResponse.status indicating a validation, but not provided any dsResponse.errors.

[tgallage]

We have subclassed RestDataSource and overriden the transformResponse method. This has been working fine since version 1.6 to 2.3. So help us how to avoid the error with smartgwt latest distribution.

The code is as follows.


protected void transformResponse(DSResponse response, DSRequest request, Object jsonData) {
super.transformResponse(response, request, jsonData);
if (jsonData == null) {
return;
}
JSONArray jsonArray = null;
Map map = null;
jsonArray = XMLTools.selectObjects(jsonData, "/responseErrors");
try{
map = (jsonArray != null && jsonArray.size()>0) ? JSOHelper.convertToMap(jsonArray.get(0).isObject().getJavaScriptObject()) : null;
}catch(Exception ex){
GWT.log("Error: Can not parse responseErrors from JSON response.", ex);
}
if (map!= null && map.size() > 0) {
response.setStatus(DSResponse.STATUS_VALIDATION_ERROR);
//JavaScriptObject valueJS = createJavaScriptObjectForErrors(map);
response.setErrors(map);
showError(map);
} else {
response.setStatus(DSResponse.STATUS_SUCCESS);
if (request.getOperationType() == DSOperationType.FETCH) {
jsonArray = XMLTools.selectObjects(jsonData, "/responseStartRow");
Integer startRow = (jsonArray != null && jsonArray.size()>0) ? (int) jsonArray.get(0).isNumber().doubleValue() : null;
if (startRow != null) {
response.setStartRow(startRow);
}

jsonArray = XMLTools.selectObjects(jsonData, "/responseEndRow");
Integer endRow = (jsonArray != null && jsonArray.size()>0) ? (int) jsonArray.get(0).isNumber().doubleValue() : null;
if (endRow != null) {
response.setEndRow(endRow);
}

jsonArray = XMLTools.selectObjects(jsonData, "/responseTotalRows");
Integer totalRows = (jsonArray != null && jsonArray.size()>0) ? (int) jsonArray.get(0).isNumber().doubleValue() : null;
if (totalRows != null) {
response.setTotalRows(totalRows);
}

}else if (request.getOperationType() == DSOperationType.ADD
|| request.getOperationType() == DSOperationType.UPDATE
|| request.getOperationType() == DSOperationType.REMOVE) {
showSuccess(request.getOperationType());
}e
}

}


Here showError() and showSuccess() are methods are used to display response status in our system's information pane.

[Isomorphic]

Once again:

So, look at the DSResponse object your code produces - the error message suggests that you've set dsResponse.status indicating a validation, but not provided any dsResponse.errors.

If your code produces a dsResponse as described above, that's always been incorrect, and now there's error handling code that catches this case.

[tgallage]

If error handling is added to the new version , how do we set error state in client side widgets that parsed from the server side error messages ?

Otherwise is it ok to avoid setting error status and errors in DSResponse which we can handle them..

Please give details how to send error information to client side in RestDatasource scenario.

[Isomorphic]

OK, need you to really carefully read this sentence:

So, look at the DSResponse object your code produces - the error message suggests that you've set dsResponse.status indicating a validation, but not provided any dsResponse.errors.

There's no mysterious new behaviors here. Everything about how you report errors works exactly as it did before.

The problem is, it appears that your code has always produced a DSResponse with the validation error code set (-4) but no actual validation errors. This has always been an invalid thing to do, the difference is, in older versions it was silently ignored, in newer versions we warn about it.

[tgallage]

I understand.

Why it is still giving an WARN message since Map of errors has been set with response.setErrors(map).
Error Map(key=field name, value = error message)

Or else response.setStatus(DSResponse.STATUS_FAILURE) should have ok logically. Still It s giving WARN message.

[Isomorphic]

Did you just say that you're setting a general failure status (-1) and then providing validation errors? That's also incorrect. To provide validation errors, use the status for validation errors.

[Isomorphic]

If you need more help with this:

1. use SC.logWarn to log the status code and the errors map right before you return your modified DSResponse from transformResponse

2. provide the entire client-side log you see when this request/response is being processed

3. indicate what type of component is receiving this response

4. from the RPC tab in the Developer Console, provide:
a. the RPCRequest and DSRequest tab contents
b. the RPCResponse and DSResponse tab contents