I understand what you're saying, but still don't see that a centralized event/query system would simplify this in most apps. Let's say there's an events for every call and completion of RPCs, and for some RPCs there needs to be a wait dialog - the usual case. Now we still need code, now in one function, to decide whether a particular RPC requires the dialog. Still need code to remember whether other dialog-requiring calls are pending. Need some new way to pass determine in the event which RPC we're referring to, to even make this decision. And now I have to maintain code for how to deal with particular calls in 2 places, where the RPC is called and in this central event handler. So really the only case where this is a simpler solution is when we don't care about all of that and just bring up the same waiting dialog during every RPC call.
Whereas with a single well designed class of your own, all the code is in one place except the calls to open/close it. In fact with a bit more cleverness you can incorporate the AsyncCallbackHandler into it so that the closing gets handled automatically, perhaps even with a Cancel button that would call your onFailure instead of onSuccess if the user canceled. Then you only have a single extra piece of code, used only on the RPCs where you want the dialog, something like: rpcService.myRPCCall(String argument, new WaitingDialog(new myAsyncCallback())); WaitingDialog maintains a list of pending calls, implements AsyncCallback, and handles the incoming onSuccess/Failure calls before passing them to your own. On Apr 1, 2:46 pm, spacejunkie <priyank.pa...@gmail.com> wrote: > > You just call to create it > > before your RPC/runAsync call, and then to remove it on onSuccess and > > onFailure > > Yes, that's how its done and I'm doing it more or less the same way. > > Consider this example: > You have several components in a panel, each of which can trigger an > async call. You want to activate a shared busy indicator for any async > activity. > > You are forced to write the same code in many places. Doing this is > not a big task but maintaining it would be tedious, sooner or later, > inconsistencies would crop up. So the point is to do it in a single > place just once...or once per each logical component. > > > That one or more RPC calls are in progress > > does not imply necessarily that a waiting dialog should be showing. > > Agree. I wasn't talking about having GWT display the loading > indicator. > But some event capturing mechanism that could be applied like an > aspect if one wanted. > > I was talking about getting access to async call status and events by > registering in a single place. > Instead of having to write additional code in 2 places for each call > just to be able to catch the events. > > If we could get these events or be able query gwt about status of > calls > made through its RPC mechanism, it would simplify many use cases. > > Thanks for your comments. > > Regards, > Priyank -- 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-tool...@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.
