No just DOM events. Like I said, just disable the UI screen (i.e. popup a
modal dialogbox) until the RPC completes one way or another. That's by far
the simplest solution I can think of.
More complicated ones would involve grouping forms & specifying which are
incompatible. Then a framework would take care of disabling input on
conflicting forms that have pending RPC. This would allow the user to do as
much as possible without having to potentially wait for the server.
You can always just ignore RPC calls
if (someStaticGlobalVariable < allowedNumberOfRPCCalls) {
someStaticGlobalVariable++;
myService.rpcCall(new AsyncCallback() {
onFailure() { someStaticGlobalVariable--; }
onSuccess() { someStaticGlobalVariable--; }
});
}
the problem with that approach though is that if you don't disable user
input, the user will get frustrated wondering why they're clicking but the
web-app isn't doing anything. So disabling gives the user an indication of
what is going on & ensures that multiple RPC calls don't happen.
At the very least, just disable the widget that initiates the RPC action (if
you want to allow the user to continue editing data while the RPC is in
progress).
On Tue, Apr 28, 2009 at 12:55 AM, AirJ <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
