Building AJAX applications with Google Web Toolkit, Apache Derby, and Eclipse 3

The A in Ajax

The main difference between a asynchronous JavaScript + XML (AJAX)-enabled Web application and a traditional Web application is a: asynchronous in Ajax. Ajax applications allow browsers to update specific portions of a page without completely refreshing the entire page. This simple technique will provide a more interactive user experience, because simple Web pages are now running more like desktop applications.

From a developer's point of view, this asynchronous behavior has two key components:

The XMLHttpRequest object is a browser-defined JavaScript object that enables WEB pages to send HTTP requests and receive responses in a background thread. Unlike a traditional page request, a call does not break the user experience, and the browser does not pause while it waits for a response.

A type of callback is executed after the response completes. The callback typically uses the JavaScript Document Object Model (MODEL,DOM) to manipulate page elements based on new data. The changes on the screen are cool and the users are happy.

So the basic process is as follows: Make a call to the server, return the response, and take action on the page based on the response. In addition, it is important to remember that all operations are done in the background, without the need to wait for a busy time and refresh according to typical changes in the page in the browser.

The whole Xmlhttprequest/dom method has only one problem: it's a headache. On the one hand, each browser implements the corresponding JavaScript object individually. On the other hand, it can be tricky to get data to the server, so converting the response to useful data can be tricky. As a result, each of the truly Ajax frameworks has a simple wrapper for creating, invoking, and managing RPC. GWT is no exception.

GWT uses the multiple interface infrastructure management RPC that recalls Enterprise JavaBeans (EJB) technology, but-thank goodness-it's a lot simpler. The problem is to define a list of remote calls that the system performs. GWT implements a background channel for converting data returned to the server, making server calls, and converting the returned data back to client data. You then define what you want to do when the remote call is fully returned. It's not as simple as executing a normal Java method call, but it's not difficult.

The change that will be made to the SLICR application is to retrieve the initial list of toppings from the server database instead of hard-coded the toppings into the client code. Admittedly, this simple example will guide you through all the steps required to perform an RPC call. To easily run this example, run in managed mode. In managed mode, GWT will automatically simulate remote calls. If you use an integrated development environment (IDE), such as Eclipse or IntelliJ idea, you will get some support for running in managed mode.

Note: In the last article in this series, I'll show you how to run the server side in a normal servlet environment.

Defining services

Most of the work in the GWT procedure call is done in two classes. On the server side, define the subclass of the Remoteserviceservlet. In this class, the server data is manipulated and the value is returned to the client (or an exception is thrown, but let's be optimistic at the moment that it doesn't happen). On the client side, define a class that implements the AsyncCallback interface. In this class, you define how the client page handles data (or exceptions) when the server operation completes. In addition to these two classes, you must write some binding code that allows GWT to bind the client class and server-side classes together. Yes, that's a lot of binding code. The binding code contains two different interfaces plus some client-side code and one or two settings. But don't worry; most of the code is a sample, and if you follow it step-by-step, you will not experience any problems.

Start from the server side. The goal here is simply to generate a list of all the toppings placed in the database at the end of the previous article. The server will use the simple objectfactory in the article (see Listing 1) to help you work.

Listing 1. Topping service Implementation

public class Toppingserviceimpl extends Remoteserviceservlet
implements Toppingservice {
Public sta Tic final String DRIVER = "Org.apache.derby.jdbc.EmbeddedDriver";
public static final String PROTOCOL = "JDBC:DERBY:SLICR;"; 　　　　　　
Public List getalltoppings () {
try {
Class.forName (DRIVER). newinstance ();
Connection con = drivermanager.getconnection (PROTOCOL);
Statement s = con.createstatement (); 　　　　　　
ResultSet rs = s.executequery (
SELECT * FROM toppings order by name);
Return Objectfactory.converttoobjects (RS, topping.class); 　　　　　　
} catch (Exception e) {
E.printstacktrace ();
return new ArrayList (); 　　　　　　
} finally {
try {
Drivermanager.getconnection ("Jdbc:derby:;shutdown=true");
catch (SQLException ignore) {}
}
}
}

The first thing to notice about this piece of code is that it's really nothing magical. The requirement for GWT remote service is simple, it must extend the Remoteserviceservlet and implement an interface that you will create in the two paragraphs below.

Note: It seems like most GWT documents let you create an interface first. That's good, not a problem at all. I just thought it would be clearer to create specific code first.

In addition to that, this code has almost the same functionality as the TOPPINGTESTR example in the previous article (repackaged for use in GWT). Make a call to the Derby database, use the object factory to create the topping object, and return the toppings object.