GWT Mini Pattern: Bare Bones Entry Point Class

Don’t ever let your entry point class do anything. Why? Because the constructor of the entry point class will be called twice. Once when the object is being instantiated so that onModuleLoad can be called, and then once if your code does anything useful in the constructor. You can also have a constructor that does nothing active (XHR, modifying the DOM) in which case it won’t matter that it is called twice (except it will slow down the user’s computer a little bit.)
Here’s an example of how not to do it (sorry for the [lack of] code formatting):


public class Display implements EntryPoint {  public void onModuleLoad() {  final RootPanel rootPanel = RootPanel.get(COMPONENT_HOME_ID);  if (rootPanel != null) {  Display fd = new Display();  } }  public Display() { Window.alert("new date: "+new Date()); // more stuff }  // more stuff }

If you were to compile and execute the code above, you'd see two different alerts. Instead you want:

public class DisplayEntry implements EntryPoint {  public void onModuleLoad() {  final RootPanel rootPanel = RootPanel.get(COMPONENT_HOME_ID);  if (rootPanel != null) {  Display fd = new Display();  } }  }  class Display { // or it could be in a separate java file public Display() { Window.alert("new date: "+new Date()); // more stuff }  // more stuff }

You can also get around it by having a no-op no arg constructor (which all EntryPoint classes are required to have) and one that takes arguments that you'll use in your class to do something.

Tested on Windows, GWT 1.4.62.

State/survey of GWT widgets

GWT does not provide as near a complete set of widgets with GWT as, say, YUI. It does provide a way to integrate existing javascript widgets, as the gwt-ext and gwt-widget projects do. However, this approach is lacking compared to native GWT widget sets because

  1. They require external javascript source files, which you then have to version and your user has to download (even if you only use some of the code). These files are not subject to the GWT optimization/compilation process.
  2. The JSNI methods used to access the third party widgets can cause trouble when you’re debugging in hosted mode. See one example.

I think it would be worth the GWT team taking more action to standardize the GWT widget set. Yes, the incubator is a start, but some of the widgets there are months old. Among other things, I could not find a carousel component that didn’t depend on kilobytes of external YUI javascript.

Here’s an informal list of GWT widget toolkits that I’ve found in my searches. Most I’ve tried and found useful, some I just have looked at. Some are native, some are wrappers.

  • The GWT incubator: these are widgets, as well as documents and other tools, that might make it into GWT in the future.
  • gwt-widget: I’ve used this project in the past. Some wrappers (of scriptaculous) and some native classes (SimpleDateFormat, LightBox).
  • sphene: I like the slider and am planning to use it in a project very soon.
  • GWT-Rocket: This provides a whole framework, including many widgets and some replacements for core GWT functionality. I installed and tested their slider functionality, but haven’t looked closer than that.
  • gwt-ext: This project wraps the fine extjs js library, plus more if you pay. I have used this for grid tables and found it great.
  • ext-gwt: This project apparently re-implements extjs, by the folks who wrote extjs. Here’s more about the differences between ext-gwt and gwt-ext.
  • GWTcomponents, which appears abandoned, but might have useful components.
  • gwt-fx: not strictly a widget toolkit, but rather a way to do effects natively.

Here is a page with other libraries that I don’t have a lot of experience with, but might be worth investigating. And looking on google code turns up a large number of projects devoted to GWT extensions.

[tags]widgets, ajax toolkits[/tags]

Article on Building “Normal” Websites with GWT

Here’s an interesting article about building websites with GWT.  By ‘normal’ this author is talking about integrating GWT components into existing HTML pages, or making widgets available to non technical users.  This is in contrast to what seems like the sweet spot of GWT–building rich web applications.  (I’ve talked about these two use cases before.)  I was impressed by the author’s assessment of the GWT widget landscape and the machinations to create a vertical TabPanel and the follow up about internationalization.  I haven’t done any i18n with GWT, but the fact that you can’t change locale after load time certainly seems like a large flaw.

Google I/O

I’m off to San Francisco for Google I/O, a two day conference on focused on web application development, with a heavy focus on Google’s APIs and tools. I’m excited for sessions ranging from “Faster-Than-Possible Code: Deferred Binding with GWT” to “Underneath the Covers at Google: Current Systems and Future Directions”.

I probably won’t be live blogging the sessions, but I will try to write a wrap up post. If you’re attending, I hope to see you there.

GWT Mini Pattern: Make Your Links Friendly To All Users

Sometimes GWT widgets are used to provide functionality, like a form submission, that is easily replicable in traditional HTML. Other times, it’s not so easy to create a user interface that degrades well. Luckily, the self contained nature of widgets means that crucial functionality is typically still available to users with javascript disabled. However, you can take steps to make your site more friendly to users with javascript disabled (for whatever reason).

For the first case, where there is a viable HTML analog, the solution is to have your widget home span look something like this:

<span id="requestinfocuspan"><span class="clickable-link" id="requestinfocuspanplaceholder"><a xhref="/" mce_href="/" >Request More Info</a></span></span>

Now, if the user has javascript disabled, and they click on the href, they are sent to the appropriate HTML form. However, if the user has javascript enabled, the widget looks for a span to enable and if it sees the “requestinfocuspan” span, calls code like this:

public static Label buildClickableLink(String span, ClickListener listener) {
Element placeHolderLink = DOM.getElementById(span+"placeholder");
String contentsOfPlaceHolder = "Content unavailable";
Element placeHolderSpan = DOM.getElementById(span);
if (placeHolderSpan != null && placeHolderLink != null) {
contentsOfPlaceHolder = DOM.getInnerText(placeHolderLink);
DOM.removeChild(placeHolderSpan, placeHolderLink);
Label clickme = new Label(contentsOfPlaceHolder);

return clickme;

This code takes the contents of “requestinfocuspan”, grabs the text of the span inside it, and replaces the whole of the contents with a label. That label has the same text and a click listener attached, so there’s no bouncing of text. If a designer wants to change the text of this link, they can do so by modifying the JSP without touching (or redeploying) GWT components.The second case mentioned above, where there is no easy way to build an HTML interface for GWT functionality, can be handled by placing a link to a page explaining to the user that javascript is required, and possibly how to turn it on. An easy way to show that link for non javascript users is to use the noscript tag

<script type="text/javascript">document.write("<a xhref='/psaf&city=Boulder'>Advanced Search Form</a>");</script>
<noscript><a xhref='/'>Advanced Search Form</a></noscript>

This is a viable option here because there is no need to run the ‘buildClickableLink’ method. We don’t really need a click listener, because we have a plain href to a page that the GWT component will run on.

The other option is to use the existing link method discussed above and use the buildClickableLink method:

<span id="searchspan"><span class="clickable-link" id="searchspanplaceholder"><a
xhref="/" mce_href="/" >Advanced Search</a></span></span>

While accessibility to non javascript users is not built into GWT (although it might be on the way), you can take steps to make your widgets more friendly to these users. This is especially true if you’re merely ‘ajaxifying’ existing functionality. In addition, users with javascript enabled get a better user experience if you use some of the above methods because the text on the page doesn’t ‘jump around’ when GWT code is executed after the page is loaded.

PS Sorry for the ‘xhref’s in my links above–I’m not quite sure how to turn off the escaping that WordPress or TinyMCE does.  Please replace ‘xhref’ with ‘href’ wherever you see it.

GWT Talk at the Boulder Denver New Tech Meetup tonight

I presented on the Google Web Toolkit at the Boulder Denver New Tech Meetup tonight (presentation and useful links). It was a rush, as presentations always are. However, the adrenaline was compounded by two factors: the length of the presentation and the composition of the audience.

To present something as large in scope as GWT in 5 minutes was difficult. Though I’d been to 3 previous meetups, I didn’t have a good feel for the technical knowledge of the audience, so I aimed to keep the presentation high level. (The audience, on this particular night, was about 50/50 split between coders and non coders, as determined by a show of hands. However, almost everyone knew the acronym AJAX and what it meant.) This lack of knowledge compounded the difficulty, but I still feel I got across some of the benefits of GWT.

I’ll be writing more about what I learned about GWT in preparing for this, but I wanted to answer 3 questions posed to me that I didn’t have off the cuff answers for tonight.

1. Who is using GWT?

I looked and couldn’t find a good list. This list is the best I could do, along with this GWT Groups post. I find it rather astonishing that there’s not a better list out there, as the above list was missing some big ones (Timepedia’s Chronoscope, the Lombardi Blueprint system) as well as my own client: Colorado HomeFinder.

2. How much time does the compilation process add?

I guessed on this tonight but guessed too high. I said it was on the order of 30 seconds to a minute. On my laptop (2 cpu/2 ghz/2 gb of ram box) GWT compilation takes ~7 seconds to build incrementally (from ant, which appears to add ~2 seconds to all of these numbers) and ~21 seconds to build after all classes and artifacts have been deleted. This is for 7400 lines of code.

3. How does GWT compare to other frameworks like Dojo and YUI?

I punted on this one when perhaps I should not have. From what I can tell, GWT attacks adding dynamic behavior to web pages in a fundamentally different way. Dojo and YUI (from what I know of them) are about adding behavior to existing widgets on a page. GWT is about adding objects to a page, which may or may not be attached to existing widgets. I’ll not say more, as I don’t have the experience with other toolkits to speak authoritatively.

Also, here’s an AJAX toolkit comparison that I found.
[tags]gwt presentations, unanswered questions[/tags]

GWT Mini Pattern: Cache ‘static’ data

Using the Java marshalling API makes remote calls from GWT to a Java server quick and easy. However, each of those calls introduces performance and complexity issues. Performance, because browsers tend to limit the number of remote network calls per server. From the HTTP 1.1 RFC: “A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.” This means that if you have more than two components making network calls, the calls will queue up (and that ignores image downloads and other network connections). The complexity arises from the non linear nature of asynchronous network calls. This can lead to a program structure that is not easily understood without careful reading (‘first, we find the user, then, after that we branch, and if we have a valid user, we find their saved bookmarks from the server…’).

If you have an amount of static content that doesn’t often change from user to user, use a RequestBuilder to retrieve the data from the server. Whatever software generates the data should set headers such that the page is cached for a fair while (either via the Cache Control header or the Expires header). The first time the request is made, the browser ends up making a network request–all the way to the server. After that, the browser will return the resource from its cache, using fewer network resources and returning the data more quickly. Using this approach also makes data available across components and pages. I almost always use JSON to represent such rarely changing data, because GWT can parse that easily, though you could use some other data format as well.

Using the browser as your caching system is not free: you pay for the creating of the network call (XMLHttpRequest, etc) and the reparse of the JSON. But you aren’t going over the network, and it’s relatively transparent to all the clients. The alternative, however, of creating your own caching system, is often more daunting–especially if you want to share data across page requests. I’m not aware of any caching systems (such as ehcache) that are GWT compatible at the moment (and they’d have their own costs in terms of javascript download size). Google Gears does provide something compatible, but is not transparent to the user (Gears requires installation).

[tags]caching, gwt, leverage the browser[/tags]

GWT Mini Pattern: Configuration Reader

I’ve written about configuration options to GWT widgets before. Basically, the idea is that you have some configuration that lets the widget change behavior without redeploying or compiling code. In fact, nontechnical users (like designers) can change configuration, if it’s documented. These are the ways I know to specify configuration:

Meta tags

In the page:

<meta content="bar" name="foo" id="foo" />

Updated 4/1/2008, to have id in the meta tag attbute.

In your code:

String var = DOM.getElementProperty(DOM.getElementById("foo"), "content");

You can also request only Boolean and Int:

String var = DOM.getElementPropertyInt(DOM.getElementById("foo"), "content");

This is simple, all browsers ignore these tags, and you can place them anywhere in a page and get them read. However, attributes can only contain strings.

Hidden spans

In the page:

<span id="foo" style="display: none">bar</span>

In your code:

String var = DOM.getInnerHTML(DOM.getElementById("foo"));

This is a good choice if you want configuration to be more structured than what a tag attribute can provide--you can parse the 'var' string further.

Javascript using jsni

<script type="text/javascript">
var ID = 'bar';

And in your code:

private native String getIDAsString()/*-{
if ($wnd.ID == undefined) {
return "";
} else {
return $wnd.ID;

private Integer getID() {
Integer id = new Integer(-1);
try {
id = Integer.valueOf(getIDAsString());
} catch (NumberFormatException ignore) {}
return id;

Integer foo = getID();

This method is great when you have variables that are used by other javascript components that you'd like to leverage for your GWT component, or if you have a really complex configuration that is multiple levels in structure.

Javascript using dictionary

(As outlined here and here.)
In the page:

<script type="text/javascript">
var dictionary = {
foo: "bar"

In your code:

Dictionary theme = Dictionary.getDictionary("dictionary");
String bar = theme.get("foo");

This is good for simple hash datastructures. I haven't tried it, but from the documentation, it doesn't look like it supports anything past String key value pairs, and your module must inherit from

Regardless of your configuration method, I've found myself using a ConfigReader to isolate this logic. It looks something like this:

public class ConfigReader{

private final boolean opt1;
private final String opt2;

public ConfigReader(){
// init opt1 and opt2 using one of the four methods above.

public boolean isOpt1() {
return opt1;

public String getOpt2() {
return opt2;

GWT Mini Pattern: Use a span to enable

Since I last checked, you aren’t able to have more than one GWT module on a page.  However, each widget is independent, so it makes a lot of sense to package them up as separate modules.  Then, you have one module that inherits from all of the other ones, and therefore all the widget code gets executed.  Except, sometimes it makes sense for a widget to be on one page and not another.  The easies way I have found to do this is to use a span tag with a unique id to mark a page for a component.  Sometimes the span tag is where the component places itself–other times it just serves as a
marker for a component which manipulates the DOM in other ways.

The code often looks like this:

RootPanel rp = RootPanel.get(SPAN_ID);
if (rp != null) {

MyComponent obj = new MyComponent();

Now, if we’re on a page that this component does not make sense on, it never gets intialized, no network calls are made, etc.

One issue is that if you want to have the component in more than one place on the page, you need to handle that with special cases.  You can simply use the same id twice, because it is bad form to have more than one element with the same id on a single page–ids are supposed to be globally unique on a page.  If you could use a special tag, that’d be nice, but GWT does not support getElementsByTagName.

GWT Mini Patterns Introduction

GWT can be used to create applications and widgets. I’ve done both, but the feeling I get from reading the newsgroups is that a lot of people are using using GWT to build network applications rather than smaller chunks of functionality. So, I’m going to write a number of posts about GWT component patterns.

First off, what’s a GWT component? In my mind, it is a small bit of functionality that is better run on the client than on the server. It can have server interaction. It does not occupy the entire screen, and has to integrate into an existing HTML based application. Components are relatively self contained and can be dropped in multiple places across a website, or across different websites.

The patterns in this category are not that complicated. They just seemed to be popping up in my code more than once and I thought it’d be nice to document them. Check back here for more as I write them.

[tags]patterns,google web toolkit[/tags]

© Moore Consulting, 2003-2021 | Twitter