Well I don't want to drag this out since in the end I'm not the one
you'd have to convince!  getAsyncRequests() is unlikely because GWT
would have to add extra code and maintain that collection for
information most wouldn't use, which is quite easy to maintain on your
own if you really need.

As for the RpcEventListener you mention, this isn't a central event
dispatch, but more like the sol'n I mentioned, something that you
include as part of the RPC call.  The only difference is you want GWT
to call your callback if it implements this interface while mine just
makes that call as part of creating the callback object.  Why create
an extra callback mechanism when you KNOW that the RPC is being called
- you're calling it!  Just take the little class you show up top and
add the central dialog logic to its constructor or a factory method,
whatever suits your fancy, and you get the same functionality:

public class RPCWrapper<T> implements AsyncCallback<T> {
        private static List<AsyncCallback> pending;
        private AsyncCallback<T> cb;

        public RPCWrapper(AsyncCallback<T> userCb) {
            cb = userCb;
            pending.add(userCb);
            ...open dialog, whatever...
        }
        public static List<AsyncCallback> getPendingRpcs() {return
pending;}

        private void onReturn() {
            pending.remove(cb);
            if (pending.isEmpty()) { ...close dialog, whatever }
        }

        public final void onFailure(Throwable caught) {
                onReturn();
                GWT.log("RPC -> onFailure() - " +
caught.getMessage());
                cb.onFailure(caught);
        }

        public final void onSuccess(T result) {
                onReturn();
                GWT.log("RPC -> onSuccess()");
                cb.onSuccess(result);
        }
}

rpcService.callMyRPC(String args, new RPCWrapper(new
myAsyncCallback());

And now you can add this to any existing RPC call without changing the
callback interface at all.

jk

On Apr 2, 3:56 am, spacejunkie <[email protected]> wrote:
> 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.

-- 
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.

Reply via email to