GWT Best Practices I

Von Elisabeth Blümelhuber , Stefanie Luipersbeck, Raffaela Brodt und Markus Popp

Für die Kommunikation zwischen Server und Client verwendet Google Web Toolkit (GWT) asynchrone Requests, um diese geht es im ersten Kapitel des shortcuts. In Webapplikationen werden komplexe Sachverhalte abgebildet, was sehr aufwendig sein kann. Doch das GWT Editor Framework schafft Abhilfe. Durch die Integration des Activities and Places Frameworks in GWT erscheint es empfehlenswert, dieses in Kombination mit dem MVP Pattern zu implementieren und so bestimmte Funktionalitäten, wie das Setzen von Bookmarks oder die Verwendung der Browserbuttons, bereitzustellen.Für moderne Webanwendungen ist es Standard, das User Interface in mehrere Sprachen bzw. für mehrere Länder zu übersetzen. Das abschließende Kapitel widmet sich dem Google Web Toolkit (GWT) und dem Spring Framework, die bereits Möglichkeiten anbieten, um Internationalisierung in eigene Anwendungen einzubauen.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 4. Feb. 2014
• ISBN: 9783868025019

Buchvorschau

GmbH

1 Asynchrone Requests und Race Conditions in GWT

Für die Kommunikation zwischen Server und Client verwendet Google Web Toolkit (GWT) asynchrone Requests [1]. Hierbei sendet der Client eine Anfrage an den Server und erhält die Antwort zeitlich versetzt, wodurch für den Nutzer der Webseite ein Weiterarbeiten ohne Blockieren des Workflows möglich ist – ein Muss für die heutigen Erwartungen an Usability.

Bei Applikationen mit größeren, komplexen User Interfaces kann dies jedoch zu Problemen in Form von Race Conditions führen. Um damit in Hinblick auf Codequalität, korrekter Funktionalität und konkreter Situation sinnvoll umzugehen, gibt es mehrere Alternativen.

1.1 Ausgangssituation

Die Spezifikation für unser Beispiel: Eine zu erstellende Webseite beinhaltet eine Listbox, die mit Werten aus einer Datenbank befüllt werden soll, sowie einen Button, der das Hinzufügen von neuen Werten ermöglichen soll. Dieser Button soll nicht angezeigt werden, wenn sich in der Datenbank bereits fünf oder mehr Werte befinden. Außerdem soll der Button unabhängig von der Anzahl der Werte in der Listbox auch dann nicht angezeigt werden, wenn eine zusätzliche Datenbankanfrage über die Rechte des Benutzers negativ ausfällt. Sichtbar ist der Button daher lediglich dann, wenn sich sowohl weniger als fünf Werte in der Listbox befinden als auch die notwendigen Rechte vorhanden sind.

In der zu unserem Beispiel zugehörigen Serviceklasse auf der Serverseite gibt es zwei Methoden: fillListbox() und hasAddRights(). Dieses reduzierte Beispiel soll die grundsätzliche Problematik zeigen, dass in einem komplexen UI einander widersprechende Wünsche betreffend der Behandlung einzelner Kontrollelemente existieren. Eine gute Diskussion zu diesem Thema findet sich unter [2].

1.2 Ein erster Versuch

Die erste, naive Umsetzung der gewünschten Funktionalität auf Clientseite zeigt Listing 1.1. Auf den ersten Blick kann diese Implementierung für einen nicht an asynchrone Requests gewöhnten Entwickler die gewünschte Funktionalität liefern. Tatsächlich erhält der Client die Ergebnisse der beiden Abfragen nur zufällig in der Reihenfolge, die zur korrekten Anzeige des UI führt. Unter Umständen kehrt nämlich der zweite Request zuerst zurück, sodass die Variable tooManyValues (noch) auf true steht. Obwohl das der Fall sein sollte, wird der Button dann auch bei entsprechenden Rechten nicht angezeigt.

Wie bei jedem Auftreten von Race Conditions ist dabei besonders unangenehm, dass das Verhalten nicht deterministisch ist. Unter Umständen wird das Fehlverhalten im Testbetrieb gar nicht bemerkt, z. B.