News

Freitag, 20. November 2009 | News

GWT 2.0 erreicht ersten Release Candidate

(Link zum Artikel: http://www.it-republik.de/jaxenter/news/052505)

Das Google Web Toolkit hat Version 2.0 Release Candidate 1 erreicht. Einge Kernfunktionalitäten des neuen Major Release lassen sich schon testen: Unter anderem wird sich die Distribution ändern, d.h. es wird künftig nur noch einen und keinen plattformspezifischen Download mehr geben. Der angekündigte Hosted Mode wird in Development Mode umbenannt, außerdem neu ist das Erstellen von deklarativen User Interfaces.

Wer sich umfassend über das Thema Google Web Toolkit informieren will, dem sei die kommende Ausgabe des Java Magazins mit einem GWT-Schwerpunkt ans Herz gelegt (ab 3. Dezember am Kiosk). Neben einer grundlegenden Einführung in das Toolkit gibt es auch einen Artikel, der die Neuerungen von GWT 2.0 im Detail vorstellt.

(cf)

Links

Anzeige

Kommentare

Gravatar Trepper 20.11.2009
um 10:27 Uhr Kennt jemand GWT _und_ Wicket und kann hier mal einen kleinen Vergleich anstellen? Würde mich wirklich mal interessieren. #zitieren
Gravatar Vanje 07.12.2009
um 14:06 Uhr Wicket ist ein komponentenbasiertes, serverseitiges Framework. D.h. der Java-Code, also die ganze Programmlogik läuft im Server ab. Im Gegensatz zu den ersten JSF-Versionen (zu neueren kann ich nichts sagen) lassen sich bestehende Komponenten leicht erweitern bzw. sehr einfach neue schreiben. Standardmäßig werden alle Benutzerdaten in der Web-Session abgelegt. Man muss sich darum nicht selber kümmern. Durch das mächtige Model-Konzept bindet man seine Daten an die Komponenten, so dass eine Änderung an den Daten automatisch die View anpasst. MVC ist hier sehr sauber umgesetzt und mit Klassen wie dem PropertyModel ergibt sich ein Hauch von dynamischer Programmierung.

Die Komponenten einer Seite oder Komponente werden in erweiterten HTML-Templates definiert. Normale HTML-Tags wie input oder div werden mit einer spezielle Wicket-ID markiert. Im Java-Code erzeugt man sich die Komponenten ähnlich wie in Swing und verbindet sie über die Wicket-ID mit den Elementen aus dem Template. Dabei muss man immer ziemlich aufpassen, dass man wirklich immer eine eins-zu-eins-Entsprechung hat.

Wicket hat auch Ajax-Unterstützung. Z.B. kann man mit einem Ajax-Submit-Button einen Teil der Form updaten ohne die ganze Seite neu zu laden. Am Server kann man im entsprechenden Event-Handler sehr genau festlegen, welche Teile der Seite upgedatet werden sollen.

Hier stößt man aber schnell an die Grenzen. Die Seite kann immer nur einen Ajax-Call auf einmal absetzen. Weitere werden erst verarbeitet, wenn der erste fertig ist. Hat man z.B. einen lang laufenden Ajax-Call, lässt sich der Rest der Seite möglicherweise nicht mehr vernünftig benutzen, weil die dortigen Ajax-Calls warten müssen.

Da das ganze Model am Server gehalten wird, fängt man an, auch für die kleinsten GUI-Änderungen Ajax-Callbacks zu schreiben. Möchte man z.B. die Hintergrundfarbe ändern, je nachdem, ob man ein Häkchen gesetzt hat oder nicht, ist die natürliche Art das in Wicket zu machen, am Server den Zustand des Häkchens zu halten und für das Change-Event des Check-Buttons ein AjaxCallback einzurichten. Wenn der User dann da drauf klickt, wird erstmal der Server aufgerufen, am Server wird die Hintergrundfarbe des gewünschten Elements gesetzt, das Element der Ajax-Response zugefügt und an den Client zurückgeschickt. Problematisch wird es, wenn man noch andere Form-Felder dabei auswerten will. Denn diese wurden ja möglicherweise am Client geändert und sind noch nicht im Model am Server verfügbar. Also fügt man ein AjaxFormSubmitBehavior ein, ...
Bei sowas fängt man dann eher an, kleine JavaScript-Schnipsel mit an die Seite zu schicken, die sowas übernehmen. Das lässt sich wiederum sehr gut in Komponenten kapseln.

Die Lernkurve ist auch ziemlich steil. Der Anfang geht relativ leicht, aber wenn es ans Eingemachte geht, muss man sich mehr und mehr auch in den Wicket-Sourcecode einarbeiten. Dann lässt es sich aber ganz gut damit arbeiten. Allerdings fehlt ein Satz richtig gut und professionell aussehender Standardkomponenten. Hier muss man eher selbst Hand anlegen.

GWT ist vom Konzept her ganz anders. Hier schreibt man Programme, die vollständig oder zumindest zum größten Teil im Browser ablaufen. Die ganze Programmlogik und der Programmstatus: alles im Client. Die Google-Leute haben einen Java-nach-JavaScript-Compiler gebaut, der das ermöglicht. Man kann seine normalen Java-Entwicklertools wie z.B. Eclipse weiter benutzen, programmiert weiter in der gleichen Programmiersprache, der Code läuft aber später im Browser ab. Man kann sogar den Java-Code debuggen. Dazu gibt es den sogenannten Hosted-Mode. Im GWT-SDK ist ein spezieller Hosted-Mode-Browser enthalten, mit dem man während der Entwicklung das Programm ablaufen lässt. (Ab GWT 2.0 gibt es stattdessen spezielle Browser-Plugins, aber das Prinzip ist das gleiche). Im Hosted Mode wird der Java-Code nur interpretiert, wodurch das Debuggen ermöglicht wird.

Obwohl alles in Java ist, muss man natürlich schon wissen, dass man im Browser abläuft. Man hat z.B. nur einen kleinen Teil der sonst üblichen Java-Bibliotheken zur Verfügung. Einige wie z.B. zur Datumsformatierung werden in einer speziellen GWT-Version mit geliefert. Es gibt aber auch schon viele spezielle GWT-Bibliotheken. Auch alles, was auf Reflection basiert, kann nicht verwendet werden. Dafür gibt es aber Deferred Binding (siehe unten).
GWT bietet einen browserunabhängigen Zugriff auf die Browser-Funktionalität wie z.B. den eingebauten XML-Parser. Insgesamt ist es eine ganz andere Art zu programmieren, eher wie bei Desktop-Programmen. Man läuft ja auch im Client ab. Wenn nachher alles kompiliert ist, hat man einen Satz JavaScript-Kompilate, die man auf jeden Webserver deployen kann, solange man nicht die GWT-Serverfunktionalität verwendet.

Der GWT-Client kann grundsätzlich mit jeder Art von Server kommunizieren. Z.B. HTTP-GETs absetzen und XML-Response parsen. Wenn man aber einen Java-Servlet-Server wie Tomcat oder Jetty hat, kann man auch den speziellen GWT-RPC-Mechanismus verwenden. Dabei kann man Java-Klassen zwischen Client und Server hin und herschicken (die Objekte werden dann im Hintergrund serialisiert/desieralisiert).

Bei GWT fehlt auch ein Satz gutaussehender Komponenten. Aber mit ExtGWT und SmartGWT gibt es dafür gute Aufsätze. Bei mir in der Firma verwenden wir SmartGWT, das ist ein GWT-Wrapper für die JavaScript-Bibliothek SmartClient.

Bei der GWT-Programmierung muss man sich an gewisse Eigenheiten gewöhnen. Z.B. gibt es im Browser (bisher) nur einen Ausführungs-Thread. Aber man arbeitet viel mit Callbacks, wenn man z.B. einen HTTP-Call macht.
Per JavaScript Native Interface (JSNI) hat man direkten Zugriff auf JavaScript. D.h. man kann eigene JavaScript-Routinen einbetten und bestehende JavaScript-Bibliotheken anbinden. Mit den sog. OverlayTypes kann man einem JavaScript-Objekt eine Java-Klasse überstülpen und von Java aus verwenden. Nützlich, wenn man mit JavaScript-Objekten aus gewrappten Bibliotheken in Java hantieren muss und diese an die Bibliothek zurückgibt.
Eine Besonderheit von GWT ist das Deferred Binding. Das ist ein Mechanismus, um zur Compilierzeit Interfaces oder Klassen in Abhängigkeit von bestimmten Properties wie z.B. Browserversion oder Locale durch andere zu ersetzen. In GWT selbst wird das z.B. verwendet, um dem Programmierer mittels eines Interfaces eine einheitliche Programmierschnittstelle zur Verfügung zu stellen, die Implementierung aber je nach Browser auszutauschen. Dazu wird die Kombination jeder unterstützten Browserversion mit jedem Locale separat kompiliert und vorgehalten. Das kostet zwar Compilierungszeit aber zur Ausführungszeit erhält jeder Browser sofort seine auf ihn optimierte Version. Man kann auch eigene Properties hinzufügen, die nach dem gleichen Mechanismus verwendet werden. Man kann aber auch während des Compilierens z.B. Annotationen im Code auswerten und davon abhängig neue Klassen generieren. Wir haben hier z.B. damit einen XML-Mapper entwickelt. Dabei muss man die Properties der Datenklassen mit entsprechenden XPath-Notationen versehen. Die Datenklassen haben abstrakte Methoden zum Erzeugen bzw. Einlesen von XML. Mittels Deferred Binding wird dann der Code zum Erzeugen bzw. Einlesen von XML anhand der Annotationen erzeugt und damit eine konkrete Unterklasse der abstrakten Datenklasse generiert.

Wenn man sich gleichzeitig in GWT und SmartGWT einarbeiten muss, kann das schon manchmal verwirrend sein. Vor allem weil, SmartGWT noch sehr jung ist und als Wrapper einer JavaScript-Bibliothek steht man ab und an vor JavaScript-Objekten, mit denen man erstmal nichts anfangen kann.
Das Debuggen in Eclipse funktioniert sehr gut, allerdings nur Java-Code. Eingebetteter JavaScript-Code kann nicht debugt werden.

Als Fazit würde ich sagen: Man kann mit beiden Frameworks gut arbeiten. Wenn es mehr Richtung RIA gehen soll, würde ich GWT mit ExtGWT oder SmartGWT empfehlen #zitieren
Gravatar Trepper 11.12.2009
um 11:37 Uhr Danke für den guten und ausführlichen Vergleich!

Je mehr ich darüber nachdenke, desto besser gefällt mir der Ansatz von GWT. Zu HTTP passt am besten die REST-Architektur und die ist wiederum ein krasser Gegensatz zu Wicket, wo alles auf dem Server gehalten wird. Wenn eine Anwendung gut skalieren und mit verschiedensten Clients genutzt werden soll, bietet sich der Einsatz einer echten Client-Anwendung, wie man sie mit GWT erstellt, an. #zitieren
Gravatar Martin Wildam 18.12.2009
um 17:56 Uhr Ich habe mich bis jetzt noch nicht entscheiden können, aber genau auf die beiden Frameworks bin ich letztendlich bei meiner Evaluierung als Finalisten gestossen - JSF ist dann an dritter Stelle, wobei mir dort halt gefällt, daß es einen grafischen GUI-Designer gibt (zumindest in NetBeans).

Was mir bei GWT aufgefallen ist (und mit SmartGWT noch stärker): Das braucht schon bei einem kleinen Testprogramm ewig zum Kompilieren - weil ja der Schritt von Java nach Javascript noch gemacht werden muß. Auch die Ladezeit der Anwendung selbst kann schon etwas länger dauern.

Mir kommt Wicket irgendwie "sauberer" vor - auch scheint dort die Trennung in Layout und Programmlogik besser - dh die Designer können sich mit CSS und HTML austoben, ohne was zu zerstören.

Von der Einschränkung mit einer AJAX-Anfrage wußte ich noch nicht - an der Stelle übrigens auch von mir ein Danke für das ausführliche Kommentar.

Wenn ich mir die ganzen Frameworks so ansehe, habe ich aber trotzdem irgendwie das Gefühl, daß all diese RIA-Versuche sehr darunter leiden, daß ein Browser halt historisch nicht dafür gedacht war, ganze Anwendungen zu hosten.

In vielen Fällen habe ich auch das Gefühl, daß Anwendungen als Webanwendungen programmiert werden, damit man sich nicht fürchten muß, am Client durch eine Installation das ganze System zu schießen (es gibt sehr weit verbreitete Betriebsysteme, wo das immer wieder passiert ;-) ).

Dort, wo eine Installation von einem Programm nur ein Click ist, hat kaum einer ein Problem damit, sich ein "richtiges" Programm an Bord zu holen - und dann auch wirklich nur die Daten zu verschicken (bei GWT hole ich mir ja im Prinzip immer die ganze Anwendung - und hoffe darauf, daß das Caching im Browser richtig funktioniert, damit es nicht jedes Mal so lange dauert und trotzdem keine alten Daten im Cache bleiben, wenn sich in der Anwendung was geändert hat). #zitieren
Gravatar Vanje 18.12.2009
um 20:46 Uhr Das mit den hohen Compilierzeiten bei GWT kann ich bestätigen. Das hängt auch immer von der Kombination der Anzahl der zu unterstützenden Browser und der Anzahl der Sprachen ab, für die man kompiliert. Wobei das sich aber relativiert, da man ja nicht immer alles komplett baut. Bei uns ist der Build auf einen separaten Build-Server mit Hudson ausgelagert, so dass beim einchecken immer automatisch gebaut wird und die Unit-Tests durchlaufen. Auf den Entwickler-Rechnern reicht der Hosted-Mode normalerweise aus. Der braucht zwar auch eine Weile, um zu starten, aber dann funktioniert das Hotdeploy ganz gut, so dass man nach Änderungen den Hosted-Mode-Browser nicht verlassen muss. Ein Reload reicht aus. Ein Compilieren ist mit der 1.x GWT-Version nur nötig, wenn man einen anderen Browser testen will. In der 2er-Version ist das durch die Plugins ja nicht mehr so notwendig.

In GWT 2.0 gibt es aber auch eine Option, um nicht-optimiert zu compilieren, hab ich selbst aber noch nicht ausprobiert, weil wir noch nicht umgestiegen sind.

Ich war anfangs auch sehr skeptisch, was das ganze Thema RIA und Anwendungen im Browser betrifft. Die Möglichkeiten, die Flex und Silverlight bieten sind auch faszinierend. Aber die Plugin-Voraussetzung ist ein KO-Kriterium in einem Umfeld mit schwachbrüstigen Rechnern und restriktiven Regeln, bei denen man froh sein muss, wenn überhaupt JavaScript erlaubt ist. Spielchen wie Filme abspielen und dergleichen brauchen wir eh nicht, da ist wäre Flex eh Overkill. Da wir nach und nach und komponentenweise von Fat-Clients auf webbasierte umstellen, haben wir mittelfristig auch eine Situation, bei der webbasierte Teile der Anwendung in einem eingebetteten IE innerhalb eines Fat-Clients ablaufen. Da dann noch mit Flash zu arbeiten, wäre etwas zu viel des guten. Der Vorteil bei GWT gegenüber serverbasierten Lösungen ist eindeutig die Nähe zur GUI und zu den GUI-Elementen. Die Anwendung läuft da ab, wo auch die GUI präsentiert wird und nicht entfernt. Das erleichtert vieles. Der Server ist dann nur noch für die Dienste im Hintergrund zuständig.
Der Vorteil in Java programmieren zu können zeigt sich besonders, wenn es darum, Kollegen die zwar Java können aber keine Webprogrammierung, an GWT-Projekte heranzuführen. Die Hemmschwelle ist eindeutig niedriger und die starke Typisierung gibt Sicherheit, dass zumindest grobe Schnitzer sofort durch den Compiler angemeckert werden. #zitieren
+ Neuen Kommentar verfassen

Folgende Links könnten Sie auch interessieren

zurück zum Seitenanfang