Announcement

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

    Referencing dsResponse.status in callbacks

    Hello,

    I'm trying to check dsResponse.status > = 0 in my callbacks for DynamicForm saveData operations. If the check is true, then I execute the callback. Otherwise, I don't want to execute the callback.

    I have 2 listgrids, however, where dsResponse is not defined in the callback? Is there a different object I need to reference to check the dsResponse status for ListGrid callbacks?

    #2
    Hello senordhuff,
    I'm assuming you're performing a save on these listGrids via a call to saveEdits()
    or something similar and the callback you're referring to is the callback passed into this method as a parameter.

    In this case, the callback passed in is only fired if the dsResponse.status value returned by the server from the save operation is >= 0 -- in other words this callback is only fired on successful save (or no-op if no save was necessary).
    Like forms, ListGrids automatically handle validation errors. Other types of errors normally go to
    dataSource.handleError() and then rpcManager.handleError(). What error case are you trying to handle?

    If this doesn't address your issue, please let us know exactly what you're trying to achieve - a code snippet of the code that trips the save, and how the callback is set up along with the expected sequence of events would be very helpful

    Thanks
    Isomorphic Software
    Last edited by Isomorphic; 6 Dec 2006, 11:21.

    Comment


      #3
      Sorry I wasn't more clear.

      Here are some snippets:

      This works fine when I reference "dsResponse.status > = 0" in the callback
      Code:
      	Fund.removeData(fundProfileForm.getValuesAsCriteria("fundID"),"if(dsResponse.status>=0){deleteFundCallback();}");
      However, when I call saveAllEdits from one of my grids like this, I get an error that "dsResponse is not defined"? So, is there a different way to reference dsResponse.status with grid operations? Or do I not need to check for dsReponse.status at all?

      Code:
      assetScenarioGrid.saveAllEdits(null,"if(dsResponse.status>=0){asCallback();}");

      Comment


        #4
        In this case you don't need to check for dsResponse at all. The callback you pass into saveAllEdits() will not fire if the server threw an error (returning a status < 0).
        If the error thrown is a normal validation error, with error message, the ListGrid will also automatically handle displaying this validation error to the user.
        - Any other errors returned by the server will fall through to the RPCManager.handleError() method which by default shows the error to the user in a warning dialog box.

        If you are setting some custom error on the server and need help with handling it let us know - otherwise you should be good to go by just taking your dsResponse check out of your callback entirely

        Thanks
        Isomorphic Software

        Comment


          #5
          Hi,

          Yes, I am throwing an exception on the server and executing the following code in my catch block:

          Code:
          catch (Exception e) {
          	dsResponse.setFailure();
          	dsResponse.setData(ATErrorHandler.getExceptionText(request, e,
          						null));
          	logger.error(e.getStackTrace());
          }
          The next step is:

          Code:
          // match the response to the request
          rpc.send(dsRequest, dsResponse);
          The dsResponse.status on the server is marked as -1 at this point. But, my callback is still executing on the client. So, I thought it was necessary to add the logic to check dsResponse.status in the callback. Any idea if I'm missing something in my exception handling on the server?

          Comment


            #6
            This server code looks correct -
            Let me back up a step: What do you see happening on the client when it recieves this error from the server, and what do you want to happen?

            I know you have a callback (passed into saveAllEditValues()) that is firing even when the server returns this error during the save operation.

            Other than that - are you seeing a dialog box notifying the user of the error?

            What behavior do you want to occur once this error comes back to the client?

            thanks

            Comment


              #7
              Hi,

              This is happening as a result of a call to saveData() on a dynamicForm (fundProfileForm) when a duplicate fund name is entered causing a DuplicateKeyException on the server. I am seeing the dialog box notifying the user of the error. But, the callback to saveData() is executing anyway.

              I don't want the callback to execute when this error occurs and that is why I put in the check for dsResponse.status and then the application performed as desired (for this form). And, when I put the check of dsResponse.status on that particular call to saveData(), I assumed it was necessary on all CUD operations for forms and grids and that was what prompted my initial question.

              Comment


                #8
                Hello again,

                So it sounds like the current behavior of showing the dialog containing the error details is appropriate for your usage - but the save-callback is firing when this error occurs and should not be.

                This is actually a bug in the 5.5 SmartClient codebase. Your code is correct - you should not need to check the dsResponse status in your callback (as you observed it's not available as a parameter) -- the callback should just not be fired when the server reports an error.
                I've passed this to our development team and they are confident that this will be resolved in our next build.
                In the meantime, if you need a workaround for this issue, please let us know and we can come up with a patch, or workaround to suppress the callback in the error case for your application.

                Thanks for your patience - we should have this issue resolved very soon

                Isomorphic Software

                Comment


                  #9
                  Hello,

                  I am now running 5.5.1 and I am still seeing this same issue?

                  Comment


                    #10
                    callback for DynamicForm.saveData() vs ListGrid.saveEdits()

                    I think the problem here is a confusion between saving data on a DynamicForm using the method "DynamicForm.saveData()" and saving edits on a ListGrid, using the method "ListGrid.saveEdits()".

                    Both these methods accept a 'callback' parameter to fire after the save completes.
                    The callback from saveData() on a dynamic form is what we call a DSCallback (doc'd here ) - it will fire whether the DS operation was successful or not - and you do have to check the DSResponse.status to determine whether the save was successful on the server or not.)

                    Compare this to a save tripped by a call to 'saveEdits()' on an editable ListGrid -- In this usage the callback passed in is not a standard "DSCallback". Instead this is a simple callback that fires only if the server operation (save) was successful - and doesn't provide access to the server response as a parameter.

                    So in the first case - saveData() on a form, if you want logic to conditionally fire on successful save you will need to check the DSResponse.status code. In the second case - saveEdits() or saveAllEdits() on a ListGrid - you don't need to perform this check as the callback will only fire if the save was successful.

                    Regards
                    Isomorphic Software

                    Comment


                      #11
                      Dynamic Form Validation messages in display in one area

                      Is there any way to retrieve all the validation errors caught within a form and display it elsewhere? Perhaps outside of the dynamic form?

                      Comment


                        #12
                        See DynamicForm.showErrors(), which is an override point designed for this. The errors are available from getErrors().

                        Comment

                        Working...
                        X