Rich Internet Applications (RIA) » GWT

GWT UiBinder: Better Web App Separation of Concerns

alberto — Mon, 26 Apr 2010 09:44:10 +0000

One of the newest features introduced in Google Web Toolkit 2.0 is the “UiBinder“. This new way of building views allows the developer to use a declarative approach when doing the layout of a GWT application.

In case you have not heard about it, GWT is a set of tools that enables Java developers to develop “rich web applications” in the Java language. The term “rich web application” implies two things:

Desktop-like interaction, where a user action has immediate feedback (e.g.: input validation, search box terms suggestions, results highlighting, etc) without requiring a server round-trip (executing an HTTP request with the result of reloading the page being browsed). In the world of web applications, this is typically accomplished using Ajax (what is also what GWT does).
An application running within a browser, but using native browser technologies (HTML, CSS and JavaScript). If we were talking about applications held in browser plug-ins and running out-of-process within their own virtual machines or by mean of run-times, I would prefer to use the more general term “rich internet applications”. These are launched from a web browser but behave as black boxes for other user agents (e.g.: web crawlers).

GWT allows us is write Ajax-based “rich web applications” using the Java language instead of the traditional JavaScript. GWT takes your Java code and compiles into JavaScript, HTML, and CSS. So while you write the program in Java, it is translated into a traditional web application.

Building user interfaces in GWT

The most common approach to building desktop application interfaces is using visual components called “widgets”. For developers with Swing experience, GWT seems a marvellous step forward because it allows you to leverage most of your knowledge with far less effort than the alternatives. I say seems because this can also be of disadvantage, as I’ll show with an example.
If we had to create a web interface for a simple web search application, the most common way of doing the interface would be an HTML form for submitting the query and an HTML list to show the results:



    Search application



    Search:
    
        Query:
        
        
    


    Results:
    
        Result 1
        Result 2
        Result 3

In the case of GWT, a Swing developer might write widget and layout code like this:


public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        Widget searchBox = createSearchBox("Query:", "Go!");
        Panel searchResults = createSearchResults();

        VerticalPanel mainContainer = new VerticalPanel();
        mainContainer.add(new Label("Search:"));
        mainContainer.add(searchBox);
        mainContainer.add(new Label("Results:"));
        mainContainer.add(searchResults);

        RootPanel.get().add(mainContainer);
    }

    private Widget createSearchBox(String inputLabel, String buttonLabel) {
        HorizontalPanel searchBox = new HorizontalPanel();
        searchBox.add(new Label(inputLabel));
        searchBox.add(new TextBox());
        searchBox.add(new Button(buttonLabel));
        return searchBox;
    }

    private Panel createSearchResults() {
        VerticalPanel searchResults = new VerticalPanel();
        for (int i = 1; i <= 3; i++) {
            searchResults.add(new Label("Result " + i));
        }
        return searchResults;
    }
}

This approach is a valid one and, with some CSS styling, produces a neat interface, but it introduces a too complicated DOM structure that does not scale well for bigger applications:



    Search GWT application




    Search:
    
        
        
            
            
            
        
        
    
                Query:
             
                
            
    Results:
    
        Result 1
        Result 2
        Result 3

Compare the handcrafted HTML tags with the DOM produced using GWT widgets, and the first one is simpler. One of the reasons of the extra verbosity of the GWT one is the use of “HorizontalPanel” to layout the search box horizontally. This is a panel based in tables and it introduces a “too verbose” HTML table for the layout. In the case of a horizontal layout, we can also use a FlowPanel, altogether with some CSS styles, to avoid the search box components stacking vertically (which is the default layout for the HTML “div” elements that a “FlowPanel” produces). The problem is that this approach mixes widgets for layout with CSS for layout (not for styling) what stops being a pure widget approach.
The next thing to notice in the DOM produced by GWT is the excessive presence of GWT CSS classes (e.g.: “gwt-Label”, “gwt-TextBox”). While they are most times useful when it comes to style the widgets, they are many times not used or they do not fit always our CSS selectors strategy.
Lastly, there is a lack of HTML semantics in the DOM produced by GWT. Almost every element is a “div”. From the point of view of web standards, it is much more convenient to use an HTML list for the results as it is to use a collection of “div” elements. Producing HTML labels associated with form fields (search box label) is also a usability and accessibility improvement. Using tables for layout should be avoided.
For a real-world application that use input fields, trees, tables, “tab panels” or splitters, etc… all in the same screen, it is a good practice to get rid of the intermediate superfluous DOM elements. It reduces drastically the amount of “glue” elements, making the DOM much more compact and faster to modify. We should avoid “glue” and automatic generated code, because it needs to be compiled, loaded, executed and maintained. In the case of an overly verbose DOM structure, CSS issues may appear because of the complex structure interactions. Fixing them is akin to fixing bugs in generated code: very difficult!

Mixing HTML and Widgets

So how can we mix widgets and html properly? Before GWT version 2.0, the most common way was to use “RootPanel.get(’someId’)” to access an HTML element in the application host page, and then create an object there to attach the widgets to (ie. a “RootPanel”). If we need to embed only a few widgets in the host page, this technique suffices. But doing this in a real application with a large number of widgets becomes complex and slow.
UiBinder scales better because it does not inject widgets into the HTML of the host page. Instead, you declare your layout in a stand-alone HTML file that can be composed with other components as many times as necessary to build more complex interfaces. Composition entails componentization, allowing the developer to create subparts of the user interface (UI components) that can be packaged, re-used and tested in isolation.
But let us see how with an example:


public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        SearchComponent searchComponent = new SearchComponent();
        RootPanel.get().add(searchComponent);
    }
}


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
    }
}

Our example has been split into three files: the first one is the GWT entry point, that now only instantiates and inserts our new UI component at the interface top level. The second is an XML file representing the view and is required by UiBinder to act as a mark-up template. The third is the Java class implementing the component logic (that as of now is almost non-existent) and invoking UiBinder.
If you run this code so far, you will notice that now the appearance is exactly the same as in the handcrafted HTML and that there is not yet real integration between the view of the component (mark-up template) and the logic of the component (Java class). Let us fix this by substituting the HTML input field with a GWT “TextBox”:


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
    }
}

Notice the changes in the template where the HTML input field has been substituted by “” and also the little change in the Java class that now has a field of type “TextBox” annotated with “UiField”. When the Java class is instantiated, the UiBinder creates and injects the “TextBox” using the matching field name and “ui:field” attribute. The result is almost the same DOM structure with only some extra attribute values generated by GWT. Note that we also eliminated the “id” HTML attribute. This last change is because of a current limitation in UiBinder which does not allow defining both attributes in the same element. This issue can be solved setting the id attribute in the constructor after the UiBinder has been invoked.
As next step, let us now integrate the results list by writing out some simple HTML list elements:


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;
    @UiField
    UListElement results;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
        queryInput.getElement().setId("queryInput");
        for (int i = 1; i <= 3; i++) {
            results.appendChild(createResultsItem("Result " + i));
        }
    }

    private Element createResultsItem(String value) {
        LIElement result = Document.get().createLIElement();
        result.setInnerHTML(value);
        return result;
    }
}

The changes in the UI Binder template is almost the same as the previous one with a subtle difference: in the previous step, we integrated a GWT widget (”TextBox”) replacing the HTML input element. In this second case, we performed a to “bind” the “ul” HTML element from the view because there is no GWT list widget that matches a simple HTML list. Instead of using the API of a GWT widget, we are using the GWT DOM API to directly modify it.

Adding behaviour

Let us now go back to the first GWT approach and modify it to create the results when clicking the button. This is what your pre-UiBinder code might look like:


public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        Panel searchResults = new FlowPanel();
        Widget searchBox = createSearchBox("Query:", "Go!", searchResults);

        FlowPanel mainContainer = new FlowPanel();
        mainContainer.add(new Label("Search:"));
        mainContainer.add(searchBox);
        mainContainer.add(new Label("Results:"));
        mainContainer.add(searchResults);

        RootPanel.get().add(mainContainer);
    }

    private Widget createSearchBox(String inputLabel, String buttonLabel,
                                   Panel searchResults) {
        HorizontalPanel searchBox = new HorizontalPanel();
        searchBox.add(new Label(inputLabel));
        searchBox.add(new TextBox());
        searchBox.add(new Button(buttonLabel,
                      createClickHandler(searchResults)));
        return searchBox;
    }

    private ClickHandler createClickHandler(final Panel searchResults) {
        return new ClickHandler() {
            public void onClick(ClickEvent event) {
                for (int i = 1; i <= 3; i++) {
                    searchResults.add(new Label("Result " + i));
                }
            }
        };
    }
}

Here we introduced a “ClickHandler” that modifies the results container with some fake ones when the search button is clicked.
Doing the same with the UiBinder approach results on the following code:


public class SearchComponent extends Composite {
    interface Binder extends UiBinder {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;
    @UiField
    Button searchButton;
    @UiField
    UListElement results;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
        queryInput.getElement().setId("queryInput");
    }

    @UiHandler("searchButton")
    void buttonClick(ClickEvent event) {
        for (int i = 1; i <= 3; i++) {
            results.appendChild(createResultsItem("Result " + i));
        }
    }

    private Element createResultsItem(String value) {
        LIElement result = Document.get().createLIElement();
        result.setInnerHTML(value);
        return result;
    }
}

We introduced a “Button” GWT widget in the mark-up template together with its corresponding field in the Java class. We also moved the code creating the results to its own method annotated with “UiHandler” (take into account that the signature must be compatible with a “ClickHandler”). Finally, we removed the “form” element from the mark-up (which is not required at all in an Ajax application).
One of the core design principles in the development world is the benefits of separating logic and presentation. What would happen if now we wanted to change the place where the results appear in relation to the search box? Or, if we wanted to get rid of the “Results:” label because it is not necessary? In the first GWT approach taken, the way in which the widgets are created and nested is reflected in the Java code together with our logic, making necessary changes to this code. Also “static” presentational elements, like the “Results:” label, are embedded in the code where. Applying the separation of concerns principle tells us that they do not belong there. Making a change to either presentation or logic necessarily requires changing both presentation and logic. In the “UiBinder” approach, because of its inherent separation of concerns, these changes would happen only in the mark-up template or in the domain logic, not in both.

Conclusions

When building a web application, no matter which framework you use, never forget that you are still using HTML, CSS and JavaScript. The simpler the DOM produced, the faster the application will perform and the less CSS issues you will find.
Web applications have web pages! Always try to use the most semantic HTML structure you can. It improves SEO, usability and accessibility and usually produces compact DOM structures.
Even when you program in your favourite language and do everything in code by mean of widgets, do not forget the advantages of principles like presentation and logic separation. Using UiBinder in GWT produces twice the number of files but each is simpler, cleaner, easy to manage, and easier to maintain.
With presentation separation, you can let your design team produce a HTML prototype of the different parts of your application that can be easily reused afterwards or even in parallel. Two teams being able to work in parallel reduces the project time span and using prototypes reduces the project risks.
Because different tasks require different skills, let the developers code and the designers deal with HTML and CSS. They all will be much happier and the application will be and look much better.

Jazoon ‘09: RIA and Security

Mike — Tue, 23 Jun 2009 13:54:50 +0000

Session title: RIA Security: Broken by Design
From: Joonas Lehtinen, CEO IT Mill

IT Mill is the creator of Vaadin: A 100% Java tool for RIA.

Joonas outlines a spectrum of complexity from Basic site to 3D games examples:
Web Sites (Wikipedia), AJAX Sugar (Facebook), Full RIA

He divides „Full RIA“ divide into client side vs. Server driven. Gives a crash course in GWT.

Vaadin: Apparently 100% Java and server driven, which sounds an awful lot like ULC at this stage… But here’s a difference: It builds on GWT and relies on JavaScript on the client-side.

He goes on to present a bunch of development rules:

Rule #1: Don’t trust the browser
Rule #2: Complexity is a hiding place for bugs
Rule #3: Large surface give more opportunities for attack. This surface has increased with Web 2.0.

Difference between GWT and Vaadin architectures is that GWT relies on the client invoking a server-side Web Service API, whereas Vaadin renders the client’s view on the server.

Erm… he then offers the cures for the problems (Rules above)… which I miss because the explanation is compressed into around 5s.

I’m starting to dislike this presentation at this point. Because here comes another artificial security issue scenario… which guess which product solves. And I thought product placement in Hollywood movies was irritating.

The issues he raises are legitimate, but the lack of objectivity is obscuring the message. And as I write the presenter is debugging JavaScript which depends on analysing the DOM on the client side – I’m not sure if he’s now analysing the problem or trying to fix it!?

I am formally declaring myself lost at this stage. At least I hope the other attendees are getting something out of this presentation, which has lost focus IMO.

He continues with a discussion about attacking at the transport level, inserting new data on the fly. But come on: A secure transaction in this technical setting will operate under HTTPS, which in most instances will deal with this kind of attack. Unless, of course, that’s something else I missed.

I think I need a coffee!!!

Computerworld.ch on GWT and UltraLightClient

admin — Mon, 04 Aug 2008 09:37:03 +0000

Here is a link to an older Computerworld.ch article comparing Google Web Toolkit and Canoo’s Java RIA library, UltraLightClient (in German only).

Google Web Toolkit und Ultra Light Client

Die Anbindung an das Internet und ein Browser gehören heute zur Standardausrüstung eines jeden Arbeitsplatzrechners oder Heim-PCs.

Stefan Thomas

Viele neue Anwendungen werden darum als HTML-basierte Web-Anwendungen implementiert, die leicht verteilt und aktualisiert werden können und von überall, zu jeder Zeit genutzt werden können. Durch den Einsatz von AJAX-Technologien konnte die Benutzerfreundlichkeit der Oberflächen in den letzten Jahren deutlich gesteigert werden, allerdings bei gleichzeitig wachsender Komplexität in der Anwendungsentwicklung. Bibliotheken, Toolkits und Frameworks versprechen hier eine Erleichterung. Beispielsweise durch die Abstraktion der unterschiedlichen JavaScript-Implementierungen der Browser oder durch vorgefertigte, komplexere Bedienelemente wie Menübalken, Tabreiter oder Baumstrukturen.

The article was written by UltraLightClient customer Dr. Stefan Thomas. Dr. Thomas is an independent consultant, that has developed two large corporate web applications with Canoo’s UltraLightClient for a global retailer.

GWT vs. ULC:

Comparing the two is a bit like comparing apples and pears (the article discusses this). On the other hand, the two widget libraries can be used for similar web applications. And both of them address Java developers.

See also the corresponding product websites:
Google Web Toolkit
Canoo UltraLightClient

Jazoon 08 Day I

admin — Wed, 25 Jun 2008 10:04:06 +0000

Here are some quick notes on the sessions I attended yesterday at Sihlcity. I believe Jazoon will be uploading videos and slides very soon:

First in my lineup was a talk on using Google Web Toolkit for a business application in a typical enterprise environment. This was kind of like a case study. Dmitry Buzdin talked about the experience his company gained and listed the various pros and cons.

Next, I listened in to Bruno Schäffer’s talk together with Christoph Henrici and Daniel Buffet of APG. The talk described the migration of an Oracle Forms application to Java forms for the advertising industry. Main requirement: development and application performance had to remain just as fast as with Oracle Forms. A requirement that the migrated application managed to over-fulfill.

Canoo’s Andreas Hölzl and Christian Stettler presented their Google Android experience report. They showed an application they developed for the Android Developer Challenge called Mobile Zoo. Their baseline: “What’s here looks promising. Let’s see the devices!”

Brian Sletten’s presentation on data-driven applications was very interesting. I particularly liked the analogy between resampling music and data.

Rich(Mobile) != Rich(Desktop)

Christian — Wed, 16 Jan 2008 08:00:57 +0000

Shortly before the end of last year, we completed a mobile demo application, which we used to analyze and investigate the status of Rich Internet Applications (RIA) technologies for mobile devices (what we will refer to as “RIA4Mobiles” within this blog post) .

The showcase application we developed describes the following scenario: field engineers use a mobile device to receive their daily work tasks or orders (called “mission” in our application) which they need to complete for that day and to communicate certain states such as “starting to work on mission X” or “completed mission Y” to a back office team application. The field engineer can use the mobile device to book the time spent and material used for a certain mission, so that the back office team can directly process the billing once a mission has been completed. In addition, the back office team can send “high prio” missions to a specific field engineer.

After having a look at different architectural approaches (ranging from device-specific fat clients to browser-based generic Web applications), we decided to go with an in-between approach: a GWT application tailored for mobile devices that runs in a generic, JavaScript-enabled mobile browser and connects to a server-side service infrastructure to fetch data and post back state changes.

For the target devices, we used a brand-new iPhone and an older iPAQ (about two years old, running Windows Mobile 2003).

The back office application is written in server-side Java, using UltraLightClient as the RIA technology.

Here is a screenshot of the mobile client:

Here is a screenshot of the corresponding back office application (click on the image to view a larger screenshot):

Instead of going into the gory technical details here (we will do that in a future posting), let me discuss some of the lessons learned:

First, the approach chosen (GWT application + “Web services”) works for mobile applications. We were able to deliver the mobile application to the mobile device. Nevertheless, there are some shortcomings:

whereas the generic, browser-based approach supports any device that hosts an up-to-date browser (with JavaScript support enabled), it also prevents a tight integration into the device itself: the look and feel is not completely “native”, its usability may be different from the concepts known from other device-native applications, and the application shows a “low fidelity”. In addition, the reuse of existing device-specific applications such as map tools, address book or telephony application is either impossible or only achievable in a device-specific way (e.g. the iPhone supports dialing numbers from a website that are encoded as a URL with link type “tel://”, other devices may support the “callto://” link type, others may not support this functionality at all). A browser-based mobile application is somehow isolated from the device, running in its own world. This is especially irritating as two of the most current developments in the mobile world, Google’s Android and Sun’s Java FX Mobile, propagate an application model that is based on the reuse of existing applications available on the mobile device.
one evil thing we know from the desktop world also holds true for the mobile world: browser hell. There is no „write once, run anywhere“ (not even with GWT’s cross-browser abstraction layer). This is due to the fact that there are various different mobile browser products and versions available on the market. Some of them are state-of-the-art and support a wide set of JavaScript and CSS features, others provide no JavaScript support at all (or only a very small subset of the language). Some of the good browsers are not available for free (such as Opera Mobile). Tweaking CSS properties and pixels was part of the daily business while developing the showcase application.
in mobile scenarios, (bad, broken) connectivity is an important topic, and so is offline capability. Thanks to the client-side JavaScript-based approach of GWT, offline “reading” is possible to a certain extent, but modifying data offline and synchronizinig the changes back to the server has very narrow limits in a browser-based world. Typically, there is no on-device persistent storage (such as a local database) available for browser-based application, as the browser builds some kind of a sandbox for that application. Ideas and projects such as Google Gears aim to ease those limitations, but currently require the installation of additional software (i.e. a browser plugin) on the mobile device.
even in times with high-end mobile devices such as the iPhone, performance issues on mobile devices are ubiquitous. The rendering performance is often poor, resulting in disturbing lags when rendering large option lists or tables (on the iPAQ device, even DOM manipulations on small HTML-based tables lead to unwanted “update effects”).

In addition to these shortcomings, rooted in the architectural approach chosen for the showcase, another thing became obvious to us: Rich(Mobile) != Rich(Desktop):

one important difference when it comes to “rich”, especially related to the usability aspect of richness, is the fact that on mobile devices, users do not have a mouse pointer. Mobile users use either a pen, their fingers, or a navigation button (for devices without touch screens). These facilities reduce pointing precision. There is no “mouse move” equivalent as there is no difference between moving the pointer and activating the pointer (as soon as you touch the screen, an event is triggered). This reduces the number of available gestures and thus, prevents applications from using some of this gestures for interaction (e.g. hovering effects or tooltips are normally not supported on touch screen devices due to the lack of “mouse move” events). A further effect of the reduced set of useful gestures for mobile devices and the corresponding pointing devices is that gestures often get “overloaded” (on the iPhone, for example, dragging means “scroll the web page”, and not “perform a drag and drop operation”).
the set of useful UI widgets is reduced as a consequence of the low-precision pointing device and the small screen size. Widgets such as spinners that allow toggling a value up and down using small arrows is not very usable on a mobile device, the same applies to scrolling in large lists (guess why the iPhone provides enhanced support for selecting a value from a combobox shown on a Web page).
the general layout-policy for mobile devices differs from desktop-based RIAs: whereas on desktop RIAs, layouts such as the dock layout are often used to provide as much flexibility to the user as possible and let the user choose almost any desired application with as little clicks as possible, mobile applications use a stack-based layout that limits the information displayed and the actions available to the user at a given moment. A mobile application needs to reduce the application context to the most important information and actions at any given time. This layout resembles the page-based approach of old-school Web applications that the one of modern RIAs.

The bottom line: RIA4Mobiles developers will need to focus a lot more on usablility, device limitations and richness compared to the development of desktop RIAs in order to deliver highly usable, responsive and appealing mobile RIAs.

All in all, RIA4Mobiles is an exciting new application area. Stay tuned to hear more about our showcase application!

Building a Regular Website with the Google Web Toolkit – Part II

danip — Wed, 18 Apr 2007 09:45:34 +0000

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.

Building a Regular Website with the Google Web Toolkit

danip — Tue, 13 Mar 2007 10:02:18 +0000

The Idea

Many nice and home-grown websites contain a navigation bar. But without a special design tool a navigation bar is not easy to build because it typically involves JavaScript programming. My idea was to build a simple and convenient tool such that a non-technical person with basic knowledge about static HTML can easily include a corresponding navigation bar in its pages.

The person configures the navigation bar by composing or adjusting a rather simple XML file. The HTML writer should not have to deal with server-side page scripting or anything a like. For the website to work, it should be sufficient to deploy the XML and a bunch of static HTML files along with some ready-made magic. Trying out the site should be as easy as double-clicking the main HTML file in the local file system.

I like Java and I did not want get my hands dirty with JavaScript and browser compatiblity issues. So how could I get the job done? Since I also like experimenting, I decided to give the GWT (the Google Web Toolkit) a go for the project.

When reading the GWT’s documentation, its seemed like the perfect choice for me: I program my navigation bar entirely in Java and in the end, it is all converted to a highly optimized and pure client-side JavaScript / HTML mash. Wow!

In the following, you can read about my related experience with the GWT and the many unexpected hurdles a had to take in order to reach my goal.

Here is a brief summary about the problems I encountered and my general impression, after playing with the GWT:

The GWT misses (at least) some basic widgets, you may expect in an Ajax (library).
(At least some) of the existing widgets are difficult to extend.
The asynchronous programming model of the GWT (and Ajax in general) leads to problems,
when creating higher level API. (You are forced to give it an asynchronous design, too.)
The GWT does not well support dynamic locale changes (details will follow in an upcoming blog entry).

Although I was really enthusiastic about the GWT when I started, I have to admit that I got disappointed here and there.
An upside is the GWT’s basic infrastructure (i.e. the compiler and the debugger), which seems very mature and stable.
It’s really just the library that should be improved…

Getting in Touch with the GWT

If you are a reasonably experienced Java programmer, then getting started with the GWT is easy, and the quick results are motivating. So, after trying out some basic stuff, I wanted to make shure that the GWT API indeed allows me to realize my little project.

The Navigation Bar Hassle

The GWT library contains a widget, which is close to the kind of navigation bar I had in mind: the class com.google.gwt.user.client.ui.TabPanel. Unfortunately, it allows for creating horzitontal navigation bars only.

When looking at the GWT kitchen sink example, it seems like there is a vertical navigation bar included – but that impression is misleading. The vertical navigation bar in the kitchen sink does not use a ready-made GWT widget. Instead, it is a custom built thing made out of a bunch of hyperlink objects (of type com.google.gwt.user.client.ui.Hyperlink)

I wondered why Google did not add a built-in vertical tab panel and so I began to read the source code of the
TabPanel and the affiliated TabBar class. I could not find any good reason why this widget should not be vertical and so, I tried to subclass TabPanel in order to get a vertical version of it. Sadly, my attempt quickly came to a halt, because the TabPanel had not at all been created with extensibilty in mind. The first few lines of code of GWT’s TabPanel reads as follows:

public class TabPanel ... {
...
private DeckPanel deck = new DeckPanel();
private TabBar tabBar = new TabBar();
private TabListenerCollection tabListeners;

/**
* Creates an empty tab panel.
*/
public TabPanel() {
VerticalPanel panel = new VerticalPanel();
panel.add(tabBar);
panel.add(deck);
...

The TabPanel is a composite widget, which consists of simpler widgets, namely a vertical panel, a tab bar and a deck panel. However, given the code from above, none of these contained widgets can be exchanged by subclassing, and therefore, it is practically impossible to get a vertical tab panel by by subclassing TabPanel.

I felt disappointed: If the set of built-in widgets is small, then at least I expect a good degree of extensibilty of the corresponding framework.

So how did I get my vertical tab pane then? By copy and patch! I copied the entire TabPanel code and turned it into my so-called FlexibleTabPanel class.

Its first lines read as follows:

public class FlexibleTabPanel extends Composite implements TabListener,
SourcesTabEvents, HasWidgets, IndexedPanel {

private final WidgetCollection children = new WidgetCollection(this);
private final DeckPanel deck = new DeckPanel();
private final FlexibleTabBar tabBar;
private TabListenerCollection tabListeners;

/**
* Creates an empty tab panel.
*/
public FlexibleTabPanel(boolean horizontal) {
Panel panel = createOuterPanel(horizontal);
tabBar = createTabBar(horizontal);

panel.add(tabBar);
panel.add(deck);
...

The constructor of FlexibleTabPanel obtains a boolean, which decides, if the resulting tab pane is vertical or horizontal. The methods createOuterPanel() and createTabBar() may be overriden. Depending on the boolean flag, they create widgets for either the horizontal or the vertical case.

As you might guess, I also had to copy and patch the class com.google.gwt.user.client.ui.TabBar. I even had to subclass (the standard GWT classes) HorizontalPanel and VerticalPanel: Both classes have certain methods in common but the GWT does not factor them out in a common superclass or super interface. However, the original TabPanel class counts on these methods with respect to HorizontalPanel. Since I wanted to use the corresponding code in FlexibleTabPanel for both the HorizontalPanel and VerticalPanel, I was forced to do the following:

I created an interface, which contains the missing super class methods and it looks
as follows:
```
public interface FlexibleIndexedPanel extends IndexedPanel {
public void add(Widget w);
public void insert(Widget w, int beforeIndex);
public boolean remove(Widget index);
}
```
(IndexedPanel is an existing interface of the GWT, which just lacks the methods from above.)

I subclassed HorizontalPanel and VerticalPanel in the following ways:

public class FlexibleHorizontalPanel extends HorizontalPanel
implements FlexibleIndexedPanel {
}

public class FlexibleVerticalPanel extends VerticalPanel
implements FlexibleIndexedPanel {
}

The new classes FlexibleHorizontalPanel and FlexibleVerticalPanel offer the functionality needed in FlexibleTabPanel. So far I could not find any good reason, why the GWT does not share this functionality in a common super class of the vertical and horizontal panel already.

Building the Builder

XML and Properties Files for Configuration

As I mentioned in the beginning, I wanted the navigation bar to be configurable via an XML file. Essentially the XML file should determine the structure of the bar and its contents. I wrote a little interpreter, which parses a related XML file and and turns it into a widget object hierarchy. This is a similar approach as in frameworks such as SwiXML and ULCXML, but for my purpose, the navigation builder, as I called it, acts on a much smaller scale.

Here is a sample XML file that the navigation builder is able to digest:

This image is not yet available.

Based on this file, the interpreter creates an outer navigation bar with five tabs. The first tab has the id home, and when selected, it displays the HTML file home.html. The next two entry work similarly. The fourth entry defines an inner navigation bar, which is vertical and contains two tabs itself: The first inner tab relates to the HTML file image1.html and the second one adds the text This image is not yet available. in place.

As you can see, it’s usually HTML files, which determine, what’s displayed upon tab selection. But where do the display names of the tabs actually come from? For reasons I will explain later, I moved all of these names to Java properties files. E.g. the properties file navigation.properties for the XML file from above may look as follows:

home=Home
cv=CV
concerts=Concerts
gallery=Gallery
contact=Contact
image1=Image 1
image2=Image 2

Every id defined in the XML file is referenced in the properties file and is associated with an English display text.

Being Asynchronous is Contagious

After that, it was time to build the navigation builder class itself. The GWT comes with a convenient
DOM-based XML parser API and so, it was easy to write the interpreter code.
Interestingly, the way to read a corresponding XML file with the GWT has a serious impact on the entire program structure.

Reading files inside a Web page is real Ajax functionality, and the related GWT API must be used as follows:

HTTPRequest.asyncGet("myfileName", new ResponseTextHandler() {
public void onCompletion(String responseText) {
...
}
}

The code loads the file myfileName via a relative URL and upon success, the contents of the file is passed in as a string to the onCompletion() method.
Since the method asyncGet() returns its result via a callback, it is called asynchronous. The navigation builder uses asyncGet() and therefore its API became asynchronous too:

NavigationBuilder builder = new NavigationBuilder(...);
builder.buildNavigation(
new NavigationBuildHandler() {
public void onBuilt(Widget widget) {
...
}

public void onFailure() {
...
}
});

Asynchronous APIs considerably change the structure of depending programs and in the example above, an asynchronous low level API “infected” a higher level API.
In the context of the GWT this effect is hard to prevent, because the native
execution environment (Java Script) has no thread concept and no thread synchronization mechanisms.

Results

After putting it all together, I finally got a first version of the navigation bar. Follow this link to try out a corresponding example, which uses the XML file and the properties file from above.

The file GWTSample1.zip contains all the related source code.

Next week, I will talk about my adventures, when I tried to bring internationalization into the system. (Note that the code in the zip file contains the code for related feature already.)