No announcement yet.
  • Filter
  • Time
Clear All
new posts

  • #16
    Hi Isomorphic,

    Just try the following served from your http server:

        ID: "countryDS",
        dataFormat: "json",
            {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"}
        ID: "countryList",
        width:500, height:224, alternateRecordStyles:true, showAllRecords:true,
        dataSource: countryDS,
        autoFetchData: true
    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:

    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}
    The comment in the code from RPCManager.js quoted in my previous message
    Success codes other than 200 OK are somewhat obscure, but are used by Amazon S3 and possibly other REST APIs
    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.



    • #17
      Hi Erich,

      Hhmm, interesting. This problem now only happens with the LGPL version of SmartClient 6.5.1. We're looking into why this should be, but what I said about filesystem URL's seems to be a part of it - if you change the URL in your example from:
      it starts to behave as I would expect (ie, rpcResponse.status is negative, and so the fix made for 6.5.1 works). As I say, we're looking into why the original example behaves differently.

      Incidentally, the intention *is* that HTTP responses other than 200 are catchable, and you should be able to catch errors of this sort and deal with them however you like, via transformResponse(). Obviously, that isn't going to work whilst this issue is still in place, but that's the intention!

      Isomorphic Support


      • #18
        We have now solved this problem in the LGPL version. As this has been quite a long-standing issue, we have released the fix as a patch so you don't have to wait for the next maintenance release. The patch code is available in the Addendums forum.

        Isomorphic Software Support
        Last edited by Isomorphic; 7th Aug 2008, 11:59.