Tips on organizing GWT modules

My current project is at the point where I’m starting to work on an administrative UI. I wanted to package it as a separate GWT module in order to not clutter up the main application module. There is some code such as the domain model that is shared between the main app and the admin code, so the question is how to organize the modules in order to share code between them.

My first attempt was to have the admin module simply inherit the main app module named ROA in admin.gwt.xml, like this:

	<inherits name="com.roa.app.ROA" />

This had two undesired results:

• Both modules declare an entry-point, so GWT tries to load both, beginning with the inherited module.
• At GWT compile time, all the code from the inherited module was duplicated under the admin module in the war structure.

My next attempt was to have the admin and app Java packages each point to a third sister package called “common” containing the domain model and other common code. Java is happy with this, but in order for GWT to compile the common code into JavaScript, you must make it a module. So now there are three packages, each with its own module:

admin.gwt.xml
app.gwt.xml
common.gwt.xml

Admin and app each have entry points and inherit the common module, which does not define an entry point. This works fine.

In the common module, I use the source tag to include multiple directories instead of just the default client directory. Note that if you specify one or more source directories, GWT no longer compiles the client directory by default, so you have to explicitly include it, as well:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.7.1//EN" "http://google-web-toolkit.googlecode.com/svn/tags/1.7.1/distro-source/core/src/gwt-module.dtd">
<module>
	<inherits name="com.google.gwt.user.User" />

	<source path="client" />
	<source path="domain" />
	<source path="presenter" />
</module>

Also, I moved the “public” directory containing CSS and images from the admin and app packages into the common module, and discovered that GWT does not create a “common” directory in the war, but rather copies the contents of the public folder from the inherited common module into both the admin and app module directories. That’s OK, though, as my CSS and images now exist in only one place in source control.

A final note: thank goodness for Eclipse refactoring tools. The easiest way to move a package (say, com.roa.app.domain to com.roa.common.domain) is to select it in the Project Explorer, then right-click, Refactor, and Rename… It’s a bit non-intuitive to use Rename rather than the Move command, but the latter appears to work only for moving packages to another project or source folder, whereas rename allows you to “move” it within the current source folder. Eclipse automatically fixes all the package and import declarations in affected code (whew!).

Eclipse keyboard shortcut for working with interfaces

Maybe everyone knows this already, but in case not…

Put your cursor in the name of an interface (say, a Display interface nested in a GWT presenter) and press Ctrl-T. Eclipse shows you all the classes that implement the interface and you can then navigate directly to an implementing class. I frequently use this in combination with Ctrl+Alt+H to find out how a method gets called.

You can find all of my favorite keyboard shortcuts in my Eclipse Google notebook listed in the left sidebar.

More Benefits of gwt-dispatch

When you use gwt-dispatch, a single dispatch servlet handles all service requests, so you no longer need to configure individual servlets in web.xml. Furthermore, action handlers are configured in Java code, like this:

		bindHandler(FindPrayerListsAction.class, FindListsHandler.class);
		bindHandler(AddPrayerListAction.class, AddPrayerListHandler.class);
		bindHandler(DeletePrayerListsAction.class, DeletePrayerListsHandler.class);

Because all configuration is done in Java, you can rename any handler, Action, Result, etc., and the Eclipse refactoring tools automatically rename it everywhere.

And speaking of Eclipse, did you know you can type only the capital letters of a class name and hit Ctrl+Space to let Eclipse automatically expand it? For example, to type “FindPrayerListsAction” above, I could simply type “FPLA” and hit Ctrl+Space. This also works in the Open Type (Ctrl+Shift+T) and Open Resource (Ctrl+Shift+R) dialogs.

Eclipse Keyboard Shortcut of the Week

Just a quickie time-saver here. I hate having to use the mouse to navigate through code (yes, I can still use vi) as it slow and bothered my right shoulder enough over time to force me to mouse with my left hand. If you’re like me, you’ll want to know about:

Ctrl+Shift+T (Open Type) Just type the first few letters of the Java class you’re looking for, and voila, you can use the arrow keys to find exactly the right one. No more clicking on folders in Package Explorer.

Ctrl+Shift+R (Open Resource) Same drill, but works for any resource in the Package Explorer.

You can find a bunch more of my favorite keyboard shortcuts in my Eclipse Google Notebook (linked on left).

/dmc

Eclipse Tip of the Day: Rename

Ever change your mind about a field name or type name? Just move the cursor over the name and hit Ctrl+2, R to rename it. Eclipse highlights all occurrences of the variable or type name and updates them all as you type. Very cool.

/dmc