Rich Internet Applications (RIA)

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.

This entry was posted on Wednesday, April 18th, 2007 at 10:45 am by danip and is filed under AJAX, GWT. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.