I make this look good

There is beauty, maybe even art, in code.

A well written piece of code flows smoothly. It is thoughtfully designed, observes proper encapsulation and variable scoping, and possesses a cohesive purpose. And it is well formatted. Lines are indented in the proper places so that the eye can easily follow the path down into nested constructs -- if statements, loops, anonymous inner classes, etc. -- emerging again into the main line of processing. Not only the structure, but the meaning and intent of the code are important in its visage. Variable names are concise without being cryptic, descriptive without being verbose. Capitalization and underscores are consistently applied where (and if) appropriate. Consistency in these elements makes code easier to read, just as proper spelling and grammar make the written word more comprehensible. Being able to tell what code means and what it's supposed to do at a glance is thrilling to a coder. If something thrills you when you look at it, isn't it beautiful? Good code looks good. Sometimes the beauty comes from the simplicity of the code and other times from taking a very complex algorithm and rendering it in a longer and more eloquent fashion which makes the complexity melt away as each line leads you by the hand through the intricate process.

The appearance of code is something that's been on my mind recently. In a discussion today on the GWT Contributor forum, I argued that certain proposed coding style guidelines disturbed the Feng Shui of code without adding value. It may not have been my most substantive argument of all time, but I think there's something of importance in that pithy reference to what many in the western world may think of as nothing more than an interior decorating fad. Each character in each line of code should blend harmoniously and purposefully with its surroundings. Even an extra space, or lack of one, could alter the careful balance of code without necessarily impacting its function. But that loss of balance harms the readability of code. Code that is less readable is less beautiful.

I always try to write my code in a way that appears neat and tidy. I've looked back on code I wrote years ago and thought to myself "damn, that's sexy." Sometimes (maybe more often, depending on how far back I wrote the code in question) instead I wonder what the Hell I was thinking when I wrote it. But most of those head-scratchers can be polished into more appealing code. It could simply be that my personal preference in matters of style and convention have changed, and applying those new preferences is all it takes.

Like fine art, music, and other things in which beauty can be found, beautiful code is often a matter of taste. But whether you prefer C++, Java, Lisp, .NET, Ruby, PHP, ColdFusion, Lua, or any of the myriad other varieties, take a moment sometime to appreciate the code. And please, for the sake of the code-lover who comes after you, strive to make beauty in your work -- appearances count.

Introducing GwtCompilerTask

One of the first things I did when I started working with GWT was to figure out how to compile an application. I don't mean running the myApp-compile.[cmd|sh] that the setup utilities create. I mean ripping apart those compile scripts and writing an Ant script to do it. Here's how in a nutshell:

<target name="gwtc">
  <java 
      classname="com.google.gwt.dev.GWTCompiler" 
      classpathref="classpath.gwt" 
      fork="true">
    <arg value="com.foo.gwt.myapp.MyApp" />
  </java>
</target>

But this past weekend, I found I needed something a little more powerful. I was writing a build target to compile all of the demos in the GWT Incubator. I wanted to avoid having to explicitly list all of the demo modules and use a <java> task call for each one. The best way to find demo modules seemed to be starting from the demo source root directory and scanning for .gwt.xml files. Ant has a <foreach> task that will do just that. The problem then was that <foreach> identifies the module files (com/foo/gwt/myapp/MyApp.gwt.xml), but GWTCompiler requires the logical module name (com.foo.gwt.myapp.MyApp). Ant is great for manipulating files, but it doesn't have much to offer in the way of runtime String manipulation. The solution? Leverage a more full-bodied programming environment. Like Java.

So I wrote a custom Ant task to handle invoking the GWTCompiler and to bridge the gap between the module's file name and it's logical name. Here's what the demo build looks like:

<target name="gwtc" depends="compile">
  <!-- define the GwtCompilerTask -->
  <taskdef 
      name="gwtc" 
      classname="com.google.ant.GwtCompilerTask">
    <classpath>
      <path path="${project.bin}" />
      <pathelement location="${gwt.dev.jar}" />
    </classpath>
  </taskdef>

  <property name="gwtc.vm.maxMemory" value="512m" />

  <!-- gwtc supports compiling with moduleName or moduleFile.
       Use of moduleFile requires setting src so that the 
       logical module name can be determined by comparing the
       moduleFile path to the source root path. vmMaxMemory
       sets the -Xmx VM argument. -->
  <gwtc src="${gwtc.src.dir}"
        out="${gwtc.out.dir}"
        moduleFile="${gwtc.module.file}"
        style="${gwtc.js.style}"
        vmMaxMemory="${gwtc.vm.maxMemory}">
    <!-- gwtc supports nested classpath -->
    <classpath>
      <path path="${gwtc.src.dir}" />
      <path path="${project.src}" />
      <path path="${project.bin}" />
      <pathelement location="${gwt.user.jar}" />
      <pathelement location="${gwt.dev.jar}" />
      <pathelement 
        location="${gwt.tools}/lib/w3c/sac/sac-1.3.jar" />
      <pathelement 
        location="${gwt.tools}/lib/w3c/flute/flute-1.3.jar" />
    </classpath>
  </gwtc>
</target>

<target name="build.demos">
  <property 
      name="demo.src.dir"
      value="${project.root}/src-demo" />
  <property name="demo.out.dir" value="${project.root}/demo" />
  <property name="demo.js.style" value="PRETTY" />

  <!-- Scan for any file under src-demo ending in .gwt.xml. For
       each file, invoke the gwtc target. The full path to the
       file is passed to gwtc target as gwtc.module.file -->
  <foreach target="gwtc" param="gwtc.module.file">
    <param name="gwtc.src.dir" value="${demo.src.dir}" />
    <param name="gwtc.out.dir" value="${demo.out.dir}" />
    <param name="gwtc.js.style" value="${demo.js.style}" />
    <path>
      <fileset dir="src-demo">
        <include name="**/*.gwt.xml" />
      </fileset>
    </path>
  </foreach>
</target>

GwtCompilerTask can also be used for building regular single-module GWT applications. GwtCompilerTask is available in the GWT Incubator. You will need to build gwt-incubator.jar from trunk at revision 1133 or later.

Taking Command of Your GWT Application

I love interfaces in Java. When used properly, they make for code that is highly cohesive and loosely coupled. Classes that implement interfaces or declare method parameters with interfaces are easier to reuse. One of my favorite interfaces in the Google Web Toolkit is Command. Command has one method:

public void execute();

That's it. A Command can be executed. Command, like the HasValue interface in the GWT Incubator is a very simple interface. So often in programming it is these simple building blocks that give us the greatest opportunities. Let's build on Command and another basic component, Button.

public class CommandButton extends Button {
  public CommandButton(final String html, final Command command) {
    super(html);
    addClickListener(new ClickListener() {
      public void onClick(Widget sender) {
        command.execute();
      }
    });
  }
}

There. Now we can create Buttons that execute a Command when clicked. If your application uses a lot of Buttons, that saves a lot of code for adding ClickListeners. And the code you might've put in those anonymous ClickListeners is now safely encapsulated inside a reusable Command class. I use some variation on CommandButton in almost every application I build. Here's another one I use:

public class CommandLabel extends Label {
  public CommandButton(final String text, final Command command) {
    super(html);
    addClickListener(new ClickListener() {
      public void onClick(Widget sender) {
        command.execute();
      }
    });
  }
}

Almost identical to CommandButton, isn't it? This one just uses a text Label instead of a Button. You can do the same with an Image if you want (and I have). I even wrote one with a ToggleButton.

At some point, I'm going to find the time to start a library project with all of these simple Widget extensions.

public int getValue()

This week I committed my first change as a member of the GWT Incubator project. That change was to introduce an interface, HasValue. This by itself is no monumental achievement. The interface is very simple:

public interface HasValue<T> {
 T getValue();
 void setValue(T value);
}

But this simple interface will facilitate the creation of more complex features such as libraries for data binding or validation.

HasValue provides a layer of abstraction around Widgets, allowing access to the underlying data model through a common API. HasValue works with simple Widgets and data types as well as complex data types and composite Widgets.

Consider two Widgets (both from the Incubator) for selecting a Date value:

DatePicker picker = new DatePicker();
DropDownListBox<Date> dropDown = new DropDownListBox<Date>();

Both implement HasValue<Date> so you could, for example, write a BirthdayValidator that ensures the selected Date is before today. This validator would have a HasValue<Date> parameter and could validate either of the two Widgets above, or any other Widget implementing the HasValue<Date> interface, without additional coding to support those Widgets.

Right now HasValue exists only in the Incubator, but there is support for including it in the next GWT release, version 1.6. Hopefully that release will see HasValue implemented by most of the standard GWT Widgets. In the mean time, I would love to see how GWT application developers use HasValue in their own projects. If you haven't worked with the Incubator before, you'll want to setup the project locally so you can build the latest features. Here's where to start:

Setting up the GWT Incubator project