First experience on GWT

My last project involves GWT, Google Web Toolkit, which is a developer’s killer app to create Javascript-based web applications. GWT is more a presentation-layer SDK. While it involves some server aspects, such as a RPC interface to integrate with the client-side communication, a larger portion of GWT’s user API includes a Javascript runtime emulation layer of Java core API, a set of DOM manipulation API, and a library of widgets. Two GWT’s most powerful functions are GWT’s hosted mode, which enables us to debug GWT apps in a Java environment, and GWT’s Java-Javascript compiler, which translates Java source code into Javascript code, therefore, the production piece of GWT apps can run entirely in the browser. GWT will deal with most browser-compatibility issues. Developers can concentrate on developing good apps, instead of fighting with Firefox-IE-Safari-Opera battles.

Developing in GWT is very similar to writing Javascript apps with pure-Javascript libraries, except for GWT’s better capability of debugging, type-safe grammar checking, and a small portion of JDK. GWT utilizes HTML and CSS to manage layouts and styles. It can also programmatically use various layout managers (panels) to place widgets that represent different kinds of UI elements on a web page.


Course Selector

Course Selector

This is an example application I have been working. GWT uses a DockPanel to divide the page into five locations, the north (1 & 2), the west (1 & 2), the centre, the east (1 & 2), and the south (1 & 2). These locations may include one single widget respectively. However, Panels can be added to contain more than one widget. Panels are used everywhere in GWT. A widget can be decorated by placing it into a DecoratorPanel. Pop-up contents can be wrapped into a PopupPanel. Vertically or horizontally distributed widgets can be placed into a VerticalPanel or a HorizontalPanel respectively.

The following series of articles will discuss the development of this example app.

The example app’s source repository is located at:

General Representation for Drupal feeds

FeedAPI is an excellent module to deliver information from the outside world into a Drupal installation. Currently FeedAPI supports to import RSS nodes, which include most applications. But legacy systems (which are probably 3 to 7 years old) and most enterprise information systems have no RSS output that supports only a few fields as a content type. In such an occasion, a more generic format is required to feed data into Drupal with FeedAPI. One of the best practices is to acquire information from legacy systems in XML format that is supported by a FeedAPI’s parser (which is already described in the previous post). Although any format is parsable, XML is more intuitive.

Generally speaking, FeedAPI accepts a list of items that are described in the same format. To generalize FeedAPI usage of feeds, a simple XML format is proposed:

In the above example, a simple XML wrapper is used to encasulate the actual data (foo’s item description). Foo’s original XML elements an be directly ecansulated into the data field with proper namespace settings.



This element has four attributes, including id, title, description, and link. id is a unique identification string in a drupal installation, it is imported into drupal as the guid field. title and description are respectively title and description in a FeedAPI feed. When a feed in the above format is imported, these two fields are imported as the feed’s title and description. link is imported as the original_url field for a FeedAPI feed. In current implementation, guid and original_url must have at least one exist. In my SimpleXML parser implementation, guid (the id attribute) is required.

The feed tag consists of a series of node tags.


The node tag is a container for a node’s details. Currently only data tag is allowed under node tag. Other tags can also be added under node to specify any node information. node has also the four attributes that are described in feed to represent drupal-specific meta data.


The data tag is a container of the original data that is converted (or directly copied) from an original XML. A namespace is suggested to indicate the source of the data. Any XML data can be added under data tag, however, the format must be consistent so the parser is able to get the same set of information for each node.

Git on S3

The author of jgit has implemented an Amazon S3 protocol to support git fetch and git push on a S3 bucket. Anyone who compiled jgit on their systems can use jgit to push their git repositories to S3. This implementation is based on jets3t, a Java S3 client library written from the ground (Update: Sorry to mess up with this. Shawn corrects me in the comment).

Jgit’s S3 protocol implementation is similar to the http protocol in C git, and it also supports transparent client-side encryption. A S3 bucket can host “any number of repositories and acts as a root directory.” S3’s ACL mechanism protects the git repositories from the wild.

I like git, and I use github a lot. This S3 implementation does not make me leave github. However, it seems to be a fantastic backup solution for my git repositories. I am looking forward to a native C implementation.