GWT Tips 1 - Chain of Responsibility

GWT application development (and AJAX programming in general) can sometimes prove problematic for web developers who has not yet adopted the mindset of asynchronous programming. In GWT, you make a RPC as follows:

   
foo.bar(param, new AsycnCallback<object>) {
 public void onFailure(Throwable throwable) {
        // handle exception
    }
    public void onSuccess(Object result) {
        // successful execution of asynchronous RPC
    }
}
   

What if you have to make a series of RPC calls such that an RPC call only gets invoked after the previous call has succeeded. Of course we can simply wrap this series of RPC calls inside one single RPC on the server side so that the client does not have to worry about synchronising the calls, but you maybe you want to update the user interface between calls, or you may want to execute some client-side logic before making the second call.

You may start off writing code like this:

   
foo.bar(param, new AsycnCallback<object>) {
    public void onFailure(Throwable throwable) {
        ...
    }
    public void onSuccess(Object result) {
        // some client-side logic before invoking the second RPC
        foo2.bar2(param, new AsycnCallback<object>) {
            public void onFailure(Throwable throwable) {
                ....
            }
            public void onSuccess(Object object) {
                ....
            }
        }
    }
}
   

This is hard to follow and error-prone. A way to avoid nested RPC calls is to leverage the Chain of Responsibility design pattern. The main class in the design pattern is the AbstractHandler. The following is a basic implementation of this class:

   
/**
 * An abstract handler in the Chain or Responsibility design pattern.
 *
 * @author See Wah Cheng
 * @param <T>
 *     type of request object to handle
 */
public abstract class AbstractHandler<T> {

  private Handler<T> successor;

  public void setSuccessor(Handler<T> successor) {
      this.successor = successor;
  }

  public Handler<T> getSuccessor() {
      return successor;
  }

  public void handOverToSuccessor(T request) {
      if (successor != null) {
          successor.handleRequest(request);
      }
  }

  public abstract void handleRequest(T request);
}
   

Given this class, to execute a series of RPC calls, one simply has to create a concrete implementation of this AbstractHandler for each RPC call and chain them together as follows: (where InvocationContext is some kind of class encapsulating the details needed for the various RPC invocation)

   
public class FooInvoker extends AbstractHandler<Invocationcontext> {
   public void handleRequest(InvocationContext request) {
       Object param = request.getFooParam();
       foo.bar(param, new AsycnCallback<object>) {
           public void onFailure(Throwable throwable) { // handle exception }
           public void onSuccess(Object result) {
               // some client-side logic before invoking the next RPC
               // updating request object if necessary
               handOverToSuccessor(request);
           }
        }
   }
 }

 public class Foo2Invoker extends AbstractHandler<InvocationContext> {
   public void handleRequest(InvocationContext request) {
       Object param = request.getFoo2Param();
       foo2.bar2(param, new AsycnCallback<object>) {
           public void onFailure(Throwable throwable) { // handle exception }
           public void onSuccess(Object result) {
               // some client-side logic before invoking the next RPC
               // updating request object if necessary
               handOverToSuccessor(request);
           }
        }
    }
 }

 InvocationContext request;
 ...
 FooInvoker fooInvoker = new FooInvoker();
 Foo2Invoker foo2Invoker = new Foo2Invoker();
 fooInvoker.setSuccessor(foo2Invoker);
 fooInvoker.handleRequest(request);
   

OK you may be shouting, "Isn't this a lot of code for something pretty simple? Er, agile? Hello?" Yes, it is more verbose, and whether this approach offers any benefit depends on the situation. If you are making three or more RPC calls in series, I definitely think this will lead to better quality code. If, inside each callback's onSuccess method, you are doing more than just invoking the next RPC, this will certainly lead to better code. If the individual stages are needed elsewhere, this again will lead to more reusable code.

Finally, an added benefit of this is that the order of execution can be altered quite easy just by shuffling the handler order in the chain (assuming that the order of execution does not matter!)