SmartGWT – Common Pitfalls

3.4.2011 | 2 minutes of reading time

SmartGWT is a very interesting extension to develop rich client web applications. We have used this framework in a project to bring an existing client application to the web.

The countless widgets and the SmartGWT Showcase with its corresponding code snippets were very helpful during implementation phase.

In general we made good experience with the development of this library. However, we noticed a few inconsistencies which we have found workarounds for and I would like to write about here.

Problems of development

IDs of widgets

The IDs of the surface widgets should always be placed directly after the first initialization. If the ID is set after a few assignments as addCellDoubleClickHandler, one will wonder why the double click has no effect.

1list = new ListGrid();
3list.addCellDoubleClickHandler(new SearchResultDoubleClickHandler(this));

This cannot be reproduced with an isolated testcase and the latest SmartGWT 2.4 and GWT 2.2.0. Therefore it seems to be fixed or I used a nightly build.


If you use the function setKeyPressFilter of the TextItem widget problems arise when you also add an own implemented KeyPressHandler. The own KeyPressHandler unfortunately disables the KeyPressFilter. The workaround is to write an additional second KeyPressHandler, which has the same functionality as the framework KeyPressFilter and avoid using of the KeyPressFilter.

1private class NumericKeyPressHandler implements KeyPressHandler {
2        /**
3         * @see com.smartgwt.client.widgets.form.fields.events.KeyPressHandler#onKeyPress(com.smartgwt.client.widgets.form.fields.events.KeyPressEvent)
4         */
5        public void onKeyPress(KeyPressEvent event) {
6            if (!event.getKeyName().matches("[0-9]")) {
7                event.cancel();
8            }
9        }
10    }

I created a bug report for this issue: http://code.google.com/p/smartgwt/issues/detail?id=576 . This bug has been confirmed in SmartGWT version 2.4 and it is fixed in the lately nightly builds.

Problems in the interaction of SmartGWT and automated tests with the Robot Framework


The “Offline” functionality of SmartGWT is a wonderful feature to persist values ​​on the client with HTML5 features and avoid manual setting of cookies. However, we couldn´t find a keyword for our automated robotic tests, which read or write the content of the permanent browser cache. But this can be handled with a simple javascript. This example sets an entry in the “permanent browser cache”.

1Execute JavaScript  window.localStorage['${name}']='${value}';

DOCTYPE tag in the HTML Bootstrap file

The SmartGWT best practices prohibit a DocType tag in the bootstrap HTML file to start the Internet Explorer ​​in “quirks mode” for example. However, this leads to no screenshots in automated robotic testing. As solution we created an extra mainAccTest.jsp file for our selenium tests that had a doctype header and the main.jsp included. This jsp is used for the automated testing with automated screenshots enabled.

1<%@ page language="java"%>
3<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt"%>
5<!doctype html>
7<jsp:include page="main.jsp" />

For more SmartGWT expirences have a look at Testing SmartGWT Applications with Selenium and Robot Framework .

share post




More articles in this subject area\n

Discover exciting further topics and let the codecentric world inspire you.


Gemeinsam bessere Projekte umsetzen

Wir helfen Deinem Unternehmen

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.