Introduction

About a month ago I wrote about my experience when building a simple but configurable web site with help of the Google Web Toolkit (see Part I). I mentioned the hurdles that I encountered but also some motivating aspects when working with GWT.

An issue I haven’t reported on yet was my attempt to internationalize my GWT application. You might be surprised why this is even worth mentioning, since GWT includes I18N support. Well, let’s say it includes some I18N support – but it was not what I needed.

Giving GWT’s I18N a Try

The GWT developer guide explains the various I18N options of GWT (see GWT I18N) but all of them have one thing in common: The locale cannot be changed dynamically at runtime after a GWT application has been started. However, it is a common use case that you want to change an application’s locale at that point of time.

Providing Truly Dynamic I18N

Truly dynamic I18N means that use change the locale in the GUI at runtime. E.g., if the user changes a combo box entry, then all GUI labels magically obtain the newly localized values. To see what I mean, you may want to check out the result of my attempts.

The way to solve this was to write my own (but simple) resource bundle API, which is similar
to the one provided by the Java class java.util.ResourceBundle. Unfortunately, this requires quite some code including:

• a properties file reader,
• a locale class,
• a resource bundle loader.

The Resource Bundle Loader

As it turned out, implementing the resource bundle loader was far from trivial. One of the resource bundle loader’s tasks is to load and cache a properties file from the server on the basis of a given locale. You can access a bundle entry with a key string in order to obtain the best possible localized result value. The means that the loader might have to access a chain of properties files according the chain of locales (from the most specific current locale to the default locale).

To implement the loading of properties files with GWT, one must use the class HTTPRequest, which offers an asynchronous request API for loading files from the server. Unfortunately, coordinating the chained download of properties files such as described above is rather difficult to implement with an asynchronous API. (See my last blog about infectious asynchronous APIs.)

Summary

In the following I would like to give brief summary of my experiences with GWT:

Upsides:

• I liked the general concept behind GWT and I think it is the (or “a”) way to go for proper software engineering in the AJAX space.
• Getting in touch and getting familiar with GWT was easy enough and was great fun.
• The compiler and the debugger seemed stable, work well and the compiler generates efficient code.

Downsides:

• The widget library is far from complete and not engineered for extensions and reuse.
• The asynchronous GWT APIs are often inconvenient – Google should ofter synchronous variants wherever possible.
• Google’s I18N solution does not offer true dynamic locale changes. This is a serious drawback for many rich client applications.

Daniel Pfeifer and Bruno Schäffer will be presenting a talk on Java RIA patterns at the upcoming JAX in Wiesbaden/Germany.

I talked to Daniel and he said that one of the main aspects that they will talk about is the impact of rich user interaction features on the structure of a related information system. Surprisingly, rich user interaction features have a strong impact on the service layer of an information system. For example, dynamic input validation typically requires a service that compares potentially incomplete input data against existing data in a persistent storage.

The presenters believe that the so-called presentation model pattern is a crucial element to tackle the complexity of a rich internet application with potentially hundreds of interdependent views and screens. In this context Daniel will introduce a comprehensive approach on applying presentation models in order to improve development efficiency and system testability.

To complete the picture, Bruno will discuss alternatives for a resulting system architecture including the decision on how and where to make a client-server-split in a related system. In addition, Bruno will uncover many challenges and solutions when linking presentation model code and GUI code with business service layers, such as semantic and syntactic validation, business object handling and cross-layer data caching.

Mark this date in your calendar:

• JAX 07 session on “Java RIA patterns“, Tuesday 24th April 2007 at 11:45, Room 6a.

The talk will be held in German.

In my daily read, I noticed that Ryan Stewart is discussing naming alternatives in his post “Is Rich Internet Application a bad term?”

In my humble opinion, I believe the current expression “Rich Internet Applications” has helped to clarify what the current web interface technologies are all about. At Canoo, we’re using the term generically to describe web applications that offer a richer, responsive user interface. Typical RIA technologies are AJAX, Adobe Flex, or Canoo’s Java library, UltraLightClient.

Before the terms AJAX and RIA emerged, it was always difficult to find a common understanding, and we tried out various different expressions. One of them even made it to the title page of the German developer magazine, JavaMagazin:

Other Canoo News:
The JGoodies Animation Extension and ULC Subset Chooser have been migrated to UltraLightClient 6.1. See the News section of the UltraLightClient Code Community.

Canoo is presenting two RIA talks at JAX 07 in Wiesbaden/Germany:

• Bruno Schäffer and Daniel Pfeifer on Java Rich Internet Applications (RIA) patterns,
• Sibylle Peter and Matthias Huber on Mixing AJAX, Swing, and Flash.

We’ve added a case study describing a Rich Internet Application that Canoo developed for a Swiss media research organization. The online tool is used by media planners to calculate the performance of billboard advertising campaigns for a defined target group in a specific geographic region, and compare quotes for billboard advertising campaigns.

It offers a rich, responsive interface for expert users with diagrams, maps, and sortable tables, as well as easy access from any platform via the Web.

This media planning tool is entirely web-based and does not require a client-side install of the (huge) billboard performance database or the sophisticated statistical algorithms used for the tool’s performance calculations. The rather frequent updates to the billboard database are easily accommodated on the server side, without clients having to visit an update site.

The tool was implemented using Canoo’s Java RIA library, UltraLightClient.