public abstract class AbstractAsyncCallback<T> implements
AsyncCallback<T> {
private static int busy;
public final void onFailure(Throwable caught) {
GWT.log("RPC -> onFailure() - " + caught.getMessage());
doOnFailure(caught);
}
public final void onSuccess(T result) {
GWT.log("RPC -> onSuccess()");
doOnSuccess(result);
}
public void doOnFailure(Throwable caught) {
}
public abstract void doOnSuccess(T result);
}
This takes care of intercepting response events. Common functionality
goes into onSuccess and onFailure.
This can't be done for request events because call to any RPC service
goes directly to server and there's no hook to intercept these calls
before GWT sends it to the server.
------------------------
Consider this:
public interface RpcEventListener<T> extends AsyncCallback<T> {
public void onRequest();
}
Objects of this interface would be passed to the async service call.
GWT would check if the the object is an instance of this interface and
call onRequest().
That's it! That's all the support one needs from GWT.
It could me made fine grained by including all events fired by
XMLHttpRequest. But event a single method would be enough for most
cases.
One can the write support classes like the abstract class above and
get the required functionality in one place.
Additionally, there could be some API to query GWT for active
requests.
public static Collection<AsyncCallback> GWT.getAsyncRequests()
The AsyncCallback or RpcEventListener objects may also hold metadata
about which logical component they were called from or the
conversation id etc.
That way one can get more information about each request from
individual object.
On Apr 2, 2:30 am, kozura <[email protected]> wrote:
> 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 <[email protected]> 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 [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.
