It might be useful is to use a callbacks registry (perhaps the page itself) that callbacks register themselves with when they start and remove themselves when they return (successfully or otherwise). By extending AsyncCallback you can make this process transparent. As part of the remove process, if there are no outstanding callbacks still running, another event can be triggered. In your case, your validation callbacks would register themselves when they are setup and deregister themselves when they return. The last one to deregister itself would then trigger the save.
Hope this helps, Jon On Apr 28, 2:55 pm, AirJ <di.z...@gmail.com> wrote: > Sorry, "Wait" may have a misnomer here. I don't mean to have browser > block waiting for the asynchronous calls to finish. > What I mean is, before launching another asynchronous call, flush out > the AsyncCallbacks in the stack. > > In a complicated UI screen, when saving the record, each field may go > through different validation asynchronous calls. Saving the record > without waiting for the previous asynchronous calls to finish will > result in unpredictible behavior. For example, validation may change > some record value. If save is invoked before validations are finished, > old values may be saved. > > I thought DeferredCommand.addCommand() would serve the purpose. From > the javadoc > Enqueues a Command to be fired after all current events have been > handled. Note that the Command should not perform any blocking > operations. > > I am wondering if the "events" include asynchronous calls, or are they > just referring to DOM events. > > On Apr 27, 6:41 pm, Vitali Lovich <vlov...@gmail.com> wrote: > > > No. "Waiting" in the browser means it freezes it (remember - single > > threaded). Why not just disable the input fields that can lead to an RPC > > call (& some kind of processing indicator so the user understands what's > > going on) & reenable them when the call completes. > > > Just apply a proper MVC pattern & you'r code should be clean (i.e. your > > controller will disable the view when the model is busy updating the backend > > & reenable it when the model indicates it is finished). > > > On Mon, Apr 27, 2009 at 8:33 PM, AirJ <di.z...@gmail.com> wrote: > > > > Hi GWT gurus, > > > > I have a generic questions regarding asynchronous calls. Basically in > > > our gwt web application, when user clicks on "save button", the > > > application launches a bunch of asynchronous calls(validation, server > > > side callbacks). > > > > "Save" should only be invoked when all those asynchronous calls are > > > processed. > > > > One way to do it is to call "Save" in the onCallbackSuccess() method > > > of those asynchronous calls. But it will make the code very > > > unstructured and hard to trace. > > > > Essentially I need a method to flush all the queued asynchronous calls > > > before I make a new one. Will > > > DeferredCommand.addCommand() solve the problem? > > > > Thanks, > > > Di --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
