Announcement

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

    RPCRequest for DMI Calls

    For DMI calls, is there a way to get the RPCRequest or specify the request parameters for it? I need specify the prompt parameters for these type of requests, but cannot get anything to work. I am currently on SmartClient 8.1 and have been through the documentation.

    The documentation says that the following call will return the RPCRequest. The returned value however is undefined.

    DMI.call(appID, className, methodName, arg1, arg2 ...argN, callback);

    The documentation also says that I can pass in request params with the following call. This does not work either.

    DMI.call({
    appID: appID,
    className: className,
    methodName: methodName,
    arguments: [arg1, arg2, ...argN], //optional
    callback: callback, //optional
    requestParams: requestProps // optional
    });

    Any help here would be appreciated.

    #2
    I figured it out. You have to specify the information as an object.

    DMI.call({
    appID: "Platform",
    className: "EventTools",
    methodName: "getEvents",
    arguments: [isc.CacheManager.lastUpdate], //optional
    callback: callback, //optional
    requestParams: { willHandleError: true, showPrompt: false } // optional
    });

    Thanks anyway.

    Comment


      #3
      I'm using SmartGWT 3.0 trial.

      I don't understand how I can add the request params {willHandleError: true} to the DMI.call() - I suspect this is a case of confusion between SmartGWT and SmartClient code snippets.

      Code:
      DMI.call({
      appID: appID,
      className: className,
      methodName: methodName,
      arguments: arguments,
      callback: callback, 
      requestParams: {willHandleError: true}
      });
      does not compile in my client-side class.

      I tried adding an RPCRequest to my DMI method signature so I can call request.setWillHandleError(true) but that causes an error: "Unable to assign a required or optional argument ... type: com.smartgwt.client.rpc.RPCRequest.."
      This makes sense in that it's a .client class, but how do I achieve management of failures?

      Thank you for any help!

      Comment


        #4
        That's odd, didn't we cover this same question with you here?

        Comment


          #5
          Well thanks for reminding me:
          Originally posted by Isomorphic
          There's currently no equivalent in the SmartGWT API to the ability to set willHandleError in SmartClient.
          -- very similar but that was a whole different situation, and I ended up removing the exceptions from the server-side method. Now I am in a situation with a new CSU that requires me to manage server-side exceptions in DMI calls.

          I'm using non-RPC DMI, so the RPCManager option:
          Originally posted by Isomorphic
          If you throw an exception in your DMI, it will go to central error handling, which you can customize via adding your own ErrorHandler to RPCManager.
          is not the ticket.

          I rechecked my code & found I was not catching all the exceptions... some of them turn out to be derived from Throwable (not Exception per se)
          Originally posted by Isomorphic
          Another approach would be to catch the exception and not report it as an error as far as SmartGWT is concerned (leave status as 0). Then your callback will be called normally.
          Sorry I didn't look back at your earlier response, it did have the info I needed.

          Comment


            #6
            Glad to hear you are sorted out - however note that non-RPC DMI error handling still goes to RPCManager's ErrorHandler so that's a viable approach as well.

            Comment


              #7
              Before I uncovered the uncaught Throwables in the server-side method, some of the tests I tried in the RPCCallback were:
              Code:
              if (response.getStatus() < 0)
              if (response.getErrors().isEmpty())
              if (response.getStatus() == RPCResponse.STATUS_FAILURE)
              Am I correct in thinking that any/all of these strategies are what you refer to when you suggest using the RPCManager's ErrorHandler?

              Comment


                #8
                No we meant literally this API on RPCManager.

                Comment

                Working...
                X