Oliver Schmid stellt die wesentlichen Neuerungen der Google Web Toolkit-Versionen 2.1+ vor. Was bringt die Tendenz zur Integration von Best Practices und Strukturierungspatterns?

In den letzten Wochen und Monaten hatte ich die Gelegenheit, mich sowohl innerhalb eines Mandates wie auch im Rahmen meiner Doktorarbeit intensiv mit den neuen Features der aktuellen GWT Versionen auseinander zu setzen. Es gibt zahlreiche interessante Veränderungen, von welchen ich die nützlichsten Neuerungen vorstellen möchte.

Activities, Places und Views

Eine Webapplikation in verschiedene “Seiten” aufzuteilen, welche separat über eine spezielle URL angesprochen werden können, ist eine häufig gestellte Anforderung. In früheren GWT Versionen ist die konkrete Implementierung (Mapping zwischen Historylistener und Seitenaufbau, Struktur des Codes für den einzelnen Seitenaufbau, etc.) komplett den Entwicklern überlassen. Mit den Activities, Places und Views fliessen Best Practices für den Aufbau einer solchen Seitenstruktur ein. Die dazugehörige generische Funktionalität für diese Aufgabe ist nun ins Standard-Toolkit integriert. Diese “Standardisierung” hilft schneller zu entwickeln und sich schneller in “fremden” Code einzulesen. Die Entwickler werden durch die vorgegebene Struktur auch angeregt, die Effizienz des Seitenaufbaus zu überdenken.

Eine View ist eine eher schwergewichtige Komponente, welche den Code für die komplette Seitenstruktur beinhaltet. Häufig wird hierzu auch die UiBinder-Funktionalität verwendet, um diese Struktur zu deklarieren. Eine View beinhaltet keinerlei Informationen über den eigentlichen Zustand der aktuellen Applikation, sondern definiert ausschliesslich die statischen Komponenten einer Seite. Da die Instanzierung einer solchen View eher teuer ist, wird diese normalerweise in Form eines Singleton (vorzugsweise mit lazy creation) erstellt.

Eine Aktivität ist dafür zuständig, den aktuellen Zustand der Applikation auf eine View zu übertragen. Wenn also eine View dargestellt werden soll, wird eine Aktivität instanziert, welche die View-Instanz der Applikation in die DOM-Struktur einbindet und die Werte der View aktualisiert (z.B. neu laden einer Tabelle beim Seitenaufruf).

Ein Place ist eine leichtgewichtige Komponente, welche Aktivitäten zugänglich macht. Die Navigation durch die Applikation wird durch Wechsel der “Plätze” realisiert, weshalb im Normalfall auch jeder Platz ein zugehöriges URL-Token besitzt. Der Platz erstellt die Aktivität(en), welche beim Wechsel ausgeführt werden soll(en) und kann diese zudem parametrisieren. So können verschiedene Plätze dieselbe Aktivitätsklasse verwenden und deren Ausführungslogik per übergebenen Parametern manipulieren.

Cell-Widgets

Die performante Darstellung von grossen Datenmengen ist mit JavaScript an sich keine einfache Sache. Wenn die einzelnen Komponenten z.B. einer Tabelle zudem schwergewichtig sind und neben deren tatsächlichen HTML-Repräsentation zudem auch ein JavaScript-Objekt zur Verwaltung angelegt werden muss, verschlimmert sich die Situation deutlich. Aus diesem Grund werden in den aktuellen GWT-Versionen die leichtgewichtigen Cell-Widgets eingeführt. Dies ermöglichen zwar nicht mehr dieselbe feinkörnige Kontrolle über die Unterelemente der Widgets (z.B. einer Zelle einer Tabelle), sind dafür aber deutlich performanter beim Aufbau. Durch eine sehr sauber strukturierte API bleiben auch hier zahlreiche Möglichkeiten zur Anpassung der Funktionalität an eigene Bedürfnisse. Dies ist zum Teil auch nötig, da – wie für das Google Web Toolkit üblich – das saubere Implementierungs-Konzept im Vordergrund steht und der Funktionsumfang der Standard-Widgets im Vergleich zu bekannten “Rich-Widgets” von Erweiterungsbibliotheken doch eher spärlich erscheint. Nichts desto trotz scheint mir diese Strategie die Bessere zu sein, da eben die Codestruktur bewusst auf benutzerdefinierte Erweiterungen ausgelegt ist und somit je nach Anforderungen bessere Ergebnisse liefert als die z.T. unschönen Manipulationen von “fixfertigen” Widgets mit (zu) grossem Funktionsumfang.

RequestFactory, Autobeans und Editoren

Wie bereits angetönt, wird in den neueren Versionen des GWT primär auf das optimale Handling von grossen Datenmengen fokussiert. Da sich der herkömmliche GWT-RPC Mechanismus zwar gut für die Kommunikation mit einzelnen Funktionen auf der Serverseite eignet, kommt diese beim Handling von zahlreichen Objekten an ihre Grenzen. Aus diesem Grund wird mit der “RequestFactory”:
eine zusätzliche Kommunikationsmöglichkeit gebildet, welche den Datenaustausch mit Hilfe von JSON ermöglicht. Dies wird mit Hilfe von sogenannten Autobeans ermöglicht – eine Komponente, welche sich auch ausserhalb der RequestFactory als sehr nützlich bei der Kommunikation mittels JSON erweist. Die “AutoBean-Magic” erlaubt es, die JSON Struktur per Interface-Deklarationen zu definieren und übernimmt die Übersetzung von JSON zu entsprechenden Proxies und zurück. Dies hat den grossen Vorteil, dass sich der Entwickler in keinem Moment (weder auf Client- noch auf Server-Seite) mit der JSON-Struktur auseinander setzen muss und mit den Datenobjekten stets über das definierte Interface interagieren kann. Durch den Einsatz von EntityProxies können so leicht Client-seitige (Teil-)Repräsentationen von JavaBeans erstellt werden, wobei sich der notwendige Datentransfer zwischen Client und Server immer nur auf die in den Interface deklarierten Elemente beschränkt und somit ein Overhead beim Datentransfer für nicht verwendete Felder vermieden werden kann.
Doch damit noch nicht genug: Google hat dem Toolkit auch dank dieser Neuerung auch gleich noch ein “DataBinding”-Feature für Editoren spendiert. So können solche EntityProxy basierende Objekte mithilfe von Annotationen oder Konventionen an Editier-Widgets gebunden werden und erleichtern somit das Erstellen von datenbasierten Applikationen enorm.

Fazit

Die neuen Versionen haben sich den Wechsel der Major-Versionsnummer redlich verdient und insbesondere Business-Applikationen, welche eher datenlastig sind, dürften von den Neuerungen profitieren. Nachdem mit den früheren Versionen die Grundlage zur Entwicklung von umfangreichen Web-Applikationen erstellt wurde, scheint mir die Tendenz zur Integration von Best Practices und Strukturierungspatterns sehr sinnvoll. Auch bleibt es bei solchen architektonischen Hilfestellungen lediglich bei Empfehlungen und der Entwickler besitzt auch weiterhin die Entscheidungsmacht darüber, diese zu berücksichtigen oder nicht. Dies bedeutet nicht nur, dass die Abwärtskompatibilität dadurch nicht gefährdet wird, sondern auch, dass das Google Web Toolkit auch bei “unkonventionellen” Applikationen, welche nicht zwingend den Strukturen der üblichen Entwicklungen entspricht, weiterhin gute Dienste leisten kann.