Hi Isomorphic,
Just try the following served from your http server:
It tries to access a non-existing URL and will get a http status 404 from your http server. Result: GUI 'hangs', user can only escape by pressing the refresh button. rpcResponse.status = 0, evalText.match problem.
BTW: It does not matter whether you use DataSource, RestDataSource or my CustJsonRPCDataSource.
If your smartclient GUI is a bit more complex it totally ruins your GUI since the user has to hit refresh.
Of course the example above show a bug in the code (pointing to a non-existing URL) which can be soved upfront. But I guess there are real world situations which do not constitute a bug since they cannot be forseen (proxy errors, etc.).
Furthermore the Json-RPC over http 2.0 proposal demands to send back Json-RPC errors as http status codes e.g. 404, 500, etc.
I think it would be very good if one could catch this error and present an error message or handle the answer in whatever way you want.
Or in the case when you want to support the json-rpc over http 2.0 proposal (or similar APIs) it will be necessary to handle e.g. 404 just the way as status 200 since you might want to examine the body further. E.g. this could be the server's answer for a Json-RPC 2.0 'method not found' error:
The comment in the code from RPCManager.js quoted in my previous message
suggests that supporting results other than status 200 was also the intention.
Of course http status <> 200 can be handled by using dataFormat: "custom" (see CustJsonRPCDataSource) but this leads to pretty ugly near-copies of what you already implemented in DataSource.js.
Regards,
Erich
Just try the following served from your http server:
Code:
isc.DataSource.create({ ID: "countryDS", dataFormat: "json", fields:[ {name:"countryCode", title:"Code"}, {name:"countryName", title:"Country"}, {name:"capital", title:"Capital"} ], operationBindings : [ { operationType:"fetch", dataURL:"/this_path_does_not_exist/leading_to_a_404"} ] }) isc.ListGrid.create({ ID: "countryList", width:500, height:224, alternateRecordStyles:true, showAllRecords:true, dataSource: countryDS, autoFetchData: true })
BTW: It does not matter whether you use DataSource, RestDataSource or my CustJsonRPCDataSource.
If your smartclient GUI is a bit more complex it totally ruins your GUI since the user has to hit refresh.
Of course the example above show a bug in the code (pointing to a non-existing URL) which can be soved upfront. But I guess there are real world situations which do not constitute a bug since they cannot be forseen (proxy errors, etc.).
Furthermore the Json-RPC over http 2.0 proposal demands to send back Json-RPC errors as http status codes e.g. 404, 500, etc.
I think it would be very good if one could catch this error and present an error message or handle the answer in whatever way you want.
Or in the case when you want to support the json-rpc over http 2.0 proposal (or similar APIs) it will be necessary to handle e.g. 404 just the way as status 200 since you might want to examine the body further. E.g. this could be the server's answer for a Json-RPC 2.0 'method not found' error:
Code:
HTTP/1.1 404 Object Not Found Server: bluepeter/0.1 Date: Mon, 21 Jul 2008 20:32:08 GMT Content-Type: application/json-rpc Content-Length: 80 {"jsonrpc":"2.0","error":{"code":"-32601","message":"Method not found."},"id":1}
Success codes other than 200 OK are somewhat obscure, but are used by Amazon S3 and possibly other REST APIs
Of course http status <> 200 can be handled by using dataFormat: "custom" (see CustJsonRPCDataSource) but this leads to pretty ugly near-copies of what you already implemented in DataSource.js.
Regards,
Erich
Comment