Das Google Web Toolkit:
Werbung
e he ab sc g ut aus De nal i ig Or Sauberes Ajax für Java-Businessanwendungen Das Google Web Toolkit: GWT O’Reilly Michael Seemann 719-5.book Seite II Mittwoch, 9. Januar 2008 10:58 10 719-5.book Seite III Mittwoch, 9. Januar 2008 10:58 10 Das Google Web Toolkit: GWT Michael Seemann Beijing · Cambridge · Farnham · Köln · Paris · Sebastopol · Taipei · Tokyo 719-5.book Seite IV Mittwoch, 9. Januar 2008 10:58 10 Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen. Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Kommentare und Fragen können Sie gerne an uns richten: O’Reilly Verlag Balthasarstr. 81 50670 Köln Tel.: 0221/9731600 Fax: 0221/9731608 E-Mail: [email protected] Copyright der deutschen Ausgabe: © 2008 by O’Reilly Verlag GmbH & Co. KG 1. Auflage 2008 Die Darstellung eines Muntjaks im Zusammenhang mit dem Thema Google Web Toolkit ist ein Warenzeichen von O’Reilly Media, Inc. Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. Lektorat: Christine Haite, Köln Fachliche Unterstützung: Lars Schulten, Köln & Christof Vollrath, Berlin Korrektorat: Petra Bromand, Düsseldorf Satz: Tim Mergemeier, reemers publishing services gmbh, Krefeld; www.reemers.de Umschlaggestaltung: Edie Freedman, Boston & Michael Oreal, Köln Produktion: Andrea Miß, Köln Belichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; www.koeselbuch.de ISBN 978-3-89721-719-5 Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt. 719-5.book Seite V Mittwoch, 9. Januar 2008 10:58 10 Inhalt Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX ........................................................ 1 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Der Google-Weg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Über dieses Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1 Einleitung 2 Das Google Web Toolkit – eine Rundreise 15 .............................. Download und Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arbeitsprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Projekt generieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Projektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Hosted-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Web-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anpassung der Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elemente anordnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auswertung von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kommunikation mit einem Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hinzufügen einer weiteren Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15 16 17 21 22 23 24 26 28 30 32 3 Von der Idee über die Architektur zur Projektstruktur . . . . . . . . . . . . . . . . . . . . . 33 Mehr-Schichten-Architektur oder eine Schicht? . . . . . . . . . . . . . . . . . . . . . . . . . . 34 GWT-Projekte unter Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 | V 719-5.book Seite VI Mittwoch, 9. Januar 2008 10:58 10 4 Model View Controller und das GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Das Model View Controller-Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ein allgemeiner Ansatz für GWT-Dialoge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ein konkreter Dialog am Beispiel der persönlichen Daten . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 61 71 84 5 Remote Procedure Call mit dem GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Schnittstellen und Klassen des GWT-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Schnittstelle definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementierung des Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ein asynchrones Datenzugriffsobjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 87 92 93 99 6 Sitzungsverwaltung und Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Sitzungsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 108 109 114 7 Java Script Native Interface – JSNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 JSNI-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 GWT und Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 8 Kombination der GWT-Konzepte in eigenen Widgets . . . . . . . . . . . . . . . . . . . . 133 Architektur des Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Umsetzung des Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 9 Deployment und Performance-Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Der Startvorgang einer GWT-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Allgemeine Optimierung für Webanwendungen . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Know-how-Schnipsel ............................................. DeferredCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deferred Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lokalisierung und ImageBundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementierung in der Moduldefinition austauschen . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI | Inhalt 153 158 165 166 167 167 171 179 181 184 719-5.book Seite VII Mittwoch, 9. Januar 2008 10:58 10 11 Fremdbibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Einbinden der Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Übersicht Fremdbibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auswahlkriterien für Fremdbibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rocket-GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GWT-Google-APIs/Google Gears . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GWT-DND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 187 190 191 196 204 207 A Übersicht GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 B Die Moduldefinition Index .............................................. 245 ............................................................... 249 Inhalt | VII 719-5.book Seite VIII Mittwoch, 9. Januar 2008 10:58 10 719-5.book Seite IX Mittwoch, 9. Januar 2008 10:58 10 Vorwort Es ist gut anderthalb Jahre her, dass Google mit dem Google Web Toolkit (GWT) einen Weg vorgestellt hat, wie sich die Entwicklung von Ajax-Webanwendungen deutlich beschleunigen lässt. Ganz nebenbei werden wir Entwickler vor den Problemen abgeschirmt, die JavaScript mit sich bringen kann. Diese sind nämlich, gerade für Entwickler mit begründeten Berührungsängsten gegenüber Script-Sprachen (zu denen ich mich auch zähle), durchaus nicht gering. Moderne Softwareentwicklung benötigt aus meiner Sicht die Unterstützung durch funktional hervorragende Werkzeuge – wie beispielsweise Eclipse. Auch möchte ich auf die Möglichkeit automatisierter Tests nicht verzichten. Und wenn ich den Servercode in Java schreibe, dann ist es eine erhebliche Erleichterung, wenn auch der Clientcode in Java geschrieben werden kann. Genau das ist mit dem GWT möglich! Inzwischen habe ich eine ganze Reihe von Projekten mit dem Google Web Toolkit umgesetzt und bin nach wie vor begeistert. In diesem Buch werden Sie deshalb nicht nur eine nüchterne Beschreibung der Möglichkeiten des GWT finden, sondern auch von den Erfahrungen profitieren, die sich in über einem Jahr Arbeit mit diesem Werkzeug angesammelt haben. An einigen Stellen wird Ihnen der eine oder andere dargestellte Weg vielleicht etwas überstrukturiert vorkommen – wenn man aber nicht nur mal eben ein kleines Beispiel zusammenhackt, dann ist ein strukturierter Weg zwingend erforderlich, um für zukünftige Entwicklungen die Tür offen zu halten. Trotzdem muss die Entwicklung zügig vorangehen können. Nach jeder kleinen Änderungen einen vollständigen Buildprozess anstoßen zu müssen, ist da wenig hilfreich. Ich hoffe, einen annehmbaren Kompromiss gefunden zu haben (zumindest ist er das für mich). Falls Sie das nach der Lektüre des Buches anders sehen, können Sie gern mit mir darüber diskutieren. Am besten per E-Mail: [email protected]. Ein solches Buch zu schreiben ist kein Spaziergang – auch nicht beim dritten Mal. Deshalb bin ich froh, dass Kollegen und Verlag mich bei diesem Projekt sehr gut unterstützt haben. Von meinen Kollegen musste Peter Zorn das Manuskript kritisch unter die Lupe nehmen. Klaus von Einem war immer eine gute Quelle für Anregungen zur Architektur | IX 719-5.book Seite X Mittwoch, 9. Januar 2008 10:58 10 und Jens Prilop – passionierter Läufer – hat sich tatsächlich getraut, das Fitnesstagebuch, das ich in diesem Buch als durchgehendes Beispiel verwende, einem Praxistest zu unterziehen. Ob es bei der Bewältigung des Berlin-Marathons geholfen hat, werde ich erst wissen, wenn das Buch schon im Druck ist. Auf Verlagsseite möchte ich mich besonders bei Ariane Hesse für die unkomplizierte Zusammenarbeit bedanken, beim Fachgutachter Christof Vollrath für die vielen guten Kommentare zum Manuskript. Und nicht zuletzt habe ich meiner Lektorin Christine Haite für ihre Geduld zu danken. Von ihrem Sachverstand war ich begeistert. Viel Spaß bei der Lektüre! Michael Seemann Rostock, September 2007 X | Vorwort 719-5.book Seite 1 Mittwoch, 9. Januar 2008 10:58 10 KAPITEL 1 Einleitung Dieses Kapitel stellt einen kurzen Einstieg in die Materie Ajax und das Google Web Toolkit dar. Sie werden erfahren, was für mich der Begriff Ajax – absichtlich nicht AJAX – bedeutet und was das Google Web Toolkit ist. Keine Angst, ich werde nicht die einhundertste Beschreibung des XMLHttpRequest-Objektes liefern! Zum einen ist das in den letzten Jahren ausreichend erfolgt, und zum anderen kommt man beim Arbeiten mit dem Google Web Toolkit damit so gut wie gar nicht in Berührung. Außerdem werde ich kurz erläutern, wie das Buch aufgebaut ist, welche Voraussetzungen Sie als Leser mitbringen sollten und was es mit dem durchgehenden Beispiel in diesem Buch auf sich hat. Ajax Sie werden sicherlich schon einmal gehört haben oder wissen, dass AJAX für Asynchronous JavaScript and XML steht. Damit wird ein technisches Verfahren beschrieben, bei dem es darum geht, dass Browser aktualisierte Inhalte nicht mehr synchron nachladen und damit für die Zeit des Datenholens die Eingabe blockieren, sondern das Nachladen von Inhalten asynchron – also quasi im Hintergrund – erfolgt. Damit ändert sich nichts Grundsätzliches an der Art und Weise, wie der Browser mit dem Server kommuniziert, aber das sonst übliche vollständige Neuzeichnen der HTMLSeiten im Browser entfällt. Und das hat gravierende Auswirkungen für den Benutzer der Webseite und für uns als Entwickler solcher Webanwendungen. Ajax und moderne Webanwendungen Bei Webanwendungen, die mit Ajax umgesetzt sind, geht es um ein völlig anderes Bedienkonzept. Es wird nicht mehr das herkömmliche Request-Response-Verfahren benutzt, das zu einem Seitenwechsel-Arbeitsverfahren geführt hat. Dabei musste jedes Mal, wenn eine Interaktion mit einem Server erforderlich war, die Seite wieder komplett neu aufgebaut werden. Der Anwender musste sich in diesem Fall mit dem Weiterarbeiten so lange gedulden, bis die Seite wieder komplett dargestellt war. Bei umfangreichen Webformularen kann es dann ziemlich nervtötend werden, wenn wegen jedes Fehlers bei | 1 719-5.book Seite 2 Mittwoch, 9. Januar 2008 10:58 10 der Eingabe selbst simpelste Vorgänge Minuten in Anspruch nehmen. Außerdem muss sich der Anwender nach jedem Laden der Webseite neu orientieren, da die gesamte Seite ersetzt wurde. Beim asynchronen Arbeiten werden nur die Inhalte aktualisiert, die sich wirklich geändert haben. Bei einer idealtypischen Anwendung wird die Seite nach dem ersten Laden im Browser nie wieder ersetzt. Die Vorteile liegen auf der Hand: • Das Arbeiten ist zügiger möglich, weil weniger Daten und weniger einzelne Requests mit einem Server ausgetauscht werden müssen. In der Regel reicht sogar nur ein einziger Request für einen Arbeitsschritt, da das Nachladen von Scripten, Stylesheets und Bildern entfällt. • Das Ajax-Prinzip sorgt fast von sich aus dafür, dass der Anwender sich nicht nach jedem Request auf der Seite neu orientieren muss. In herkömmlichen Webanwendungen mussten die Seiten dazu homogen sein, und bei Seiten, die größer sind als das Browserfenster, musste der Entwickler dafür sorgen, dass die Seite wieder an die richtige Stelle scrollt. • Der Zustand einer Anwendung kann im Client gespeichert werden. Dadurch werden weniger Ressourcen auf dem Server benötigt. • Umfangreiche Arbeitsschritte lassen sich zusammenfassen, bis überhaupt ein Request zum Server nötig wird. Der Erfolg von Ajax-basierten Webanwendungen spricht für sich – wie z.B. das gern zitierte Beispiel Google Mail zeigt. Jeder, der selbst schon einmal mit Webanwendungen gearbeitet hat, die sich eher wie Desktop-Anwendungen und nicht wie typische Webanwendungen verhalten, wird mir sicher zustimmen, dass man dieses zügige Arbeiten nicht mehr vermissen möchte. Ajax und seine Probleme Natürlich gibt es auch Nachteile, die diese Technologie mit sich bringt: • Wenn nur minimale Änderungen an der Seite erforderlich sind, bemerkt der Anwender diese Änderung möglicherweise nicht. Deshalb muss man sich Gedanken machen, wie man dem Anwender visualisiert, dass sich etwas geändert hat, oder man verzichtet nicht ganz auf synchrones Verhalten. (Auch auf dem Desktop arbeitet man schließlich nicht gleichzeitig in zwei Fenstern – es gibt immer nur ein aktives Fenster.) • Ein-Seiten-Anwendungen sind nicht sehr suchmaschinentauglich. Diese betrachten HTML-Seiten nämlich meist als statisch – dass es eventuell Bereiche gibt, die erst per JavaScript nachgeladen werden, können sie nicht auswerten. • Die Umsetzung einer Webanwendung mit JavaScript kann sehr zeitaufwendig werden – weshalb es auch diese enorme Menge an verschiedenen Ajax-Toolkits und -Frameworks gibt. 2 | Kapitel 1: Einleitung 719-5.book Seite 3 Mittwoch, 9. Januar 2008 10:58 10 • Das Testen von Webanwendungen ist ebenfalls kein Kinderspiel, und Ajax erfordert hier noch mehr Aufwand als herkömmliche Webanwendungen. In diesen konnte beispielsweise der Quellcode für die Eingabeprüfung durch Test-Frameworks wie JUnit geprüft werden. Bei einer Ajax-basierten Webanwendung kommt neben dem Servercode aber noch JavaScript-Code dazu, der ebenfalls getestet werden muss. Beschränkt man sich auf die Betrachtung von JavaScript, um eine Ajax-Anwendung umzusetzen, dann ist diese Sprache nicht gerade der eleganteste Weg – und zwar aus folgenden Gründen: • JavaScript ist nicht typisiert. Deshalb können Fehler erst zur Laufzeit auftreten, die eine typisierte Sprache schon während des Kompilierens moniert hätte. Denken Sie an den typischen Fall des NaN-Wertes, wenn eine Zahl erwartet wird. • Die hohe Flexibilität der Sprache macht es für Werkzeuge schwierig, dem Entwickler unter die Arme zu greifen. Von den Refaktorierungsmöglichkeiten, die Eclipse beim Umgang mit Java bietet, kann man bei JavaScript nur träumen. • Von Hause aus bietet JavaScript kaum einfache Möglichkeiten, Quelltext wirklich wartbar zu strukturieren. Wie es trotzdem gehen kann, zeigt das Dojo Toolkit (http://www.dojotoolkit.org). • Trotz einer standardisierten Sprache gibt es von Laufzeitumgebung zu Laufzeitumgebung – für Webseiten also die verschiedenen Browser – Unterschiede, um die man sich als Entwickler kümmern muss. So mag der IE es überhaupt nicht, wenn man die Definition eines Arrays mit einem Komma zu viel abschließt. Der FireFox ist hier toleranter. Um nur ein Beispiel zu nennen. • JavaScript ist nur schwer zu debuggen. Das gilt besonders dann, wenn man sehr viel von den dynamischen Bestandteilen der Sprache Gebrauch macht. Auch hier gibt es inzwischen Werkzeuge und Hilfsmittel, die ein Debuggen nicht mehr nur auf die Ausgabe mit der JavaScript-Funktion alert beschränken. Als Beispiel sei hier FireBug (http://www.getfirebug.com/) genannt. Auf dieses kleine Werkzeug möchte ich auf gar keinen Fall mehr verzichten. Auch in diesem Buch wird uns dieses Werkzeug noch einmal begegnen. • Für fast alle Programmiersprachen gibt es inzwischen Test-Frameworks, wie beispielsweise JUnit für Java. Auch hier ist das Angebot für JavaScript noch eher dürftig. Warum also setzt man bei all diesen Problemen trotzdem auf JavaScript für die Realisierung von Webanwendungen? Man könnte doch auch auf Flash o. Ä. zurückgreifen. Der unschlagbare Vorteil von JavaScript ist, dass es in fast jedem Browser verfügbar ist, ohne dass ein zusätzliches Plugin installiert werden muss. Dadurch hat man eine Umgebung, die unabhängig von Browser und Betriebssystem verfügbar ist. Außerdem ist diese ScriptSprache standardisiert und ist vergleichsweise leicht zu erlernen. Ajax | 3 719-5.book Seite 4 Mittwoch, 9. Januar 2008 10:58 10 Ein anderer Aspekt bei Ajax-Anwendungen ist die Modifikation des Document Object Models (DOM) der gerade geladenen Webseite. Und hier können die unterschiedlichen Browser einem das Leben wirklich schwer machen. Wenn man dann noch beachtet, dass Browser im so genannten Quirks-Modus und in einem Strict-Modus arbeiten können und sich die Interpretationen von Maßangaben und Stylesheet-Definitionen dann unterschiedlich verhalten können, wird es gänzlich unübersichtlich. Gleiches gilt im Übrigen für die unterschiedlichen Ereignismodelle in den Browsern. Deshalb sind Hilfsmittel in Form von Toolkits oder Frameworks inzwischen Pflicht, da andernfalls eine kostengünstige Umsetzung von Projekten nicht mehr möglich ist. Quirks- und Strict-Modus Diese beiden Modi beschreiben, wie Browser ein HTML-Dokument darstellen. Der Strictoder Standard-Modus wird verwendet, wenn das geladene (X)HTML-Dokument über eine DTD verfügt, so dass die Gültigkeit des Dokuments vom Browser geprüft werden kann und diese DTD das Dokument als W3C-standardkonform ausweist. Zum Beispiel: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> oder: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Diese Bedingung erfüllen aber längst nicht alle HTML-Dokumente, die im Web verfügbar sind. Das ist aus unterschiedlichen Gründen der Fall. Entweder weil die HTML-Dokumente so alt sind, dass es zum Zeitpunkt ihrer Erstellung noch gar keine Standards gab, weil Webentwickler sich dieses Problems nicht bewusst sind oder weil ein spezielles Verhalten der Browser gewünscht wird. Aus diesem Grund schalten einige Browser in den Quirks-Modus und versuchen »das Beste« aus dem HTML-Dokument zu machen. Prinzipiell sollte man sich also am Strict-Modus orientieren, da so die größte Kompatibilität erreicht wird und die erstellten HTML-Dokumente zumindest annähernd identisch in den verschiedenen Browsern erscheinen. Mat Gessel hat sich die Mühe gemacht und das unterschiedliche Verhalten der Browser am Beispiel der Größen- und Positionseigenschaften im Browserfenster analysiert (http:// www.asquare.net/javascript/tests/ViewportTestResults.html). Diese Übersicht macht das Chaos sehr deutlich! Umsetzungsstrategien für Ajax-Anwendungen Die Strategien und Konzepte sind teilweise recht unterschiedlich, wenn es darum geht, Ajax-Anwendungen möglichst einfach und zügig zu erstellen. So gibt es einige JavaScript-Toolkits schon beinahe so lange, wie es JavaScript gibt. Zu diesen gehören neben dem bereits erwähnten Dojo Toolkit auch Prototype (http://www.prototypejs.org), script.aculo.us (http://script.aculo.us) oder die Yahoo! User Interface Library (http:// developer.yahoo.com/yui). Die Liste lässt sich beliebig fortsetzen. 4 | Kapitel 1: Einleitung 719-5.book Seite 5 Mittwoch, 9. Januar 2008 10:58 10 Neben dem Einsatz von clientseitigen JavaScript-Bibliotheken besteht auch die Möglichkeit, die Anwendungslogik auf dem Server zu belassen und den Browser nur zum »Zeichnen« der Anwendung zu benutzen. Nach diesem Prinzip arbeitet beispielsweise das Framework Echo2 (http://www.nextapp.com/platform/echo2/echo). Der Browser lädt beim Starten eine so genannte Render-Engine, die sich um das Zeichnen der Oberfläche und das Weiterleiten von Ereignissen an den Server kümmert. Auf dem Server wird verwaltet, was im Browser zu sehen ist. Wenn die Anwendungslogik Änderungen an der Oberfläche erfordert, werden mit dem Browser Nachrichten ausgetauscht, die diese Änderungen beschreiben. Die Render-Engine sorgt dann dafür, dass sich die Oberfläche im Browser ändert. Dieses Verfahren hat allerdings Grenzen, da man nicht jedes Ereignis problemlos vom Browser an den Server schicken kann. Stellen Sie sich vor, man würde jeden Tastendruck an den Server übermitteln, um die Zahl der eingetippten Zeichen zu ermitteln – vom Ajax-Gefühl wäre dann nichts mehr übrig! In der dritten Gruppe lassen sich Toolkits und Frameworks unterbringen, die eine Anwendung zunächst weitgehend ohne die spätere Laufzeitumgebung beschreiben und dann nach JavaScript oder Flash übersetzen. OpenLaszlo (http://www.openlaszlo.org/) ist ein Vertreter dieser Gruppe. Framework oder Toolkit Vielleicht haben Sie bemerkt, dass ich scheinbar wahllos die Begriffe Toolkit und Framework verwendet habe. Diese beiden Begriffe lassen sich aber ganz gut auseinanderhalten. Ein Framework zeichnet einen Lösungsweg vor. Wer ein Framework benutzt, muss sich an diesen einmal umgesetzten Lösungsweg halten. Technisch wird das so umgesetzt, dass der eigene Code vom Framework aufgerufen wird. Bei einem Toolkit ist das nicht der Fall. Man kann es einsetzen, wo man es braucht, und lässt es an den Stellen bleiben, wo es nicht sinnvoll ist. Hier rufen wir den Code des Toolkits auf. Auch das Google Web Toolkit ist kein Framework. Man könnte zwar den Aufruf der onLoadMethode so interpretieren, dass wir Code zur Verfügung stellen, der vom GWT aufgerufen wird. Eigentlich handelt es sich aber nur um eine Möglichkeit, die Anwendung zu starten. Bei allem, was danach geschieht, benutzen wir die Möglichkeiten des Toolkits wie einen Werkzeugkasten, mit dem wir unsere Anwendung erstellen. Warum eigentlich Ajax und nicht AJAX? Der Begriff AJAX legt ziemlich genau die zu verwendende Technik fest. Er setzt XML als Mittel und JavaScript als Weg voraus. Diese Definition trifft zwar auf einige Verfahren und Lösungswege zu, aber die Regel sieht heute ganz anders aus: An Stelle von XML – entweder als rohes XML für den Austausch von Daten oder aufbereitet in Form von XHTML – tritt zunehmend das Austauschformat JSON. Ajax | 5 719-5.book Seite 6 Mittwoch, 9. Januar 2008 10:58 10 JSON (JavaScript Object Notation – http://www.json.org/) ist ein einfaches Textformat für den Datenaustausch. Ähnlich wie bei XML ist es möglich, nicht nur eine Aneinanderreihung von Werten zu übermitteln, man kann in diesem Format auch komplexe hierarchische Strukturen beschreiben. Der Clou an diesem Format ist, dass es der Syntax von JavaScript entspricht. Aus diesem Grund ist es für JavaScript-Interpreter in den Browsern besonders einfach, mit diesem Format umzugehen. Außerdem ist es deutlich schneller als das Parsen von XML mit Hilfe von JavaScript. Es lassen sich Objekte, Arrays und einfache Werte benutzen. Das Textformat wird der eval-Funktion übergeben, und das Ergebnis ist ein JavaScript-Objekt, auf dessen Eigenschaften man ganz einfach mit der Punktoder Index-Notation (bei Arrays) zugreifen kann. Es gibt heute kaum noch eine Programmiersprache, für die es nicht einen Parser gibt, der mit diesem Format umgehen kann. Auch für das Serialisieren von Daten in das JSONFormat gibt es unzählige Umsetzungen. Dieses Format hat aber auch Schwächen: So ist es nicht direkt möglich, Typ-Informationen zu übermitteln. Das ist für JavaScript selbst kein Problem, da JavaScript eine untypisierte Sprache ist. Für typisierte Programmiersprachen aber schon, da es zu Fehlinterpretationen von Werten kommen kann. Das Google Web Toolkit benutzt ebenfalls JSON, sorgt aber durch eine zusätzliche Semantik dafür, dass die ausgetauschten Daten in typisierte Informationen übersetzt werden. Außerdem wird dem JSON-String ein Kommentar vorangestellt, so dass die Verwendung sicherer wird. Damit wäre das X schon mal null und nichtig. Aber auch JavaScript muss es nicht zwingend sein. Auch nicht, wenn man sich auf den Browser beschränkt. Schon seit geraumer Zeit wird neben JavaScript beispielsweise Flash für die Umsetzung von Webclients benutzt. Aus den dargestellten Gründen ist der Begriff Ajax für mich auch zunehmend allgemeiner als die spezielle, technische Abkürzung AJAX. Ajax steht für eine bessere Interaktion zwischen Anwender und Webseite, die sich mit unterschiedlichen Mitteln technisch umsetzen lässt. Letztendlich gehören also auch die Modifikation des DOM der Webseite zu diesem Begriff und damit auch die vielen bunten Effekte, die seit einigen Jahren die Webseiten optisch aufwerten. Man könnte auch sagen: Ajax ist ein Synonym für Rich Internet Application (RIA). Der Google-Weg Auch Google hat sich mit dem Google Web Toolkit für eine Lösung entschieden, bei der die Ajax-Anwendung in einer anderen Sprache als JavaScript geschrieben wird und für die Laufzeitumgebung eine Konvertierung nach JavaScript erfolgt. Da die Anwendung selbst in Java entwickelt wird, lassen sich eine Reihe der oben angesprochenen Probleme lösen: 6 | Kapitel 1: Einleitung 719-5.book Seite 7 Mittwoch, 9. Januar 2008 10:58 10 • Java ist eine typisierte Sprache und ermöglicht deshalb eine Typprüfung bereits zur Entwicklungszeit. Ein API auf Basis einer typisierten Sprache beschreibt sich bei vernünftiger Umsetzung selbst. Damit ist deren Benutzung deutlich einfacher. • Die Unterstützung der Entwicklungsprozesse ist bei Java deutlich ausgereifter als bei JavaScript. Das betrifft z.B. die Code-Refaktorierung, das Debugging und das Testen. • Durch das Kompilieren nach JavaScript kann der JavaScript-Code für die Laufzeitumgebung optimiert werden (nur erreichbarer Code wird übersetzt, keine Strukturierung des Quellcodes zur Verbesserung der Lesbarkeit, Abkürzung von Variablennamen …). Warum man sich bei Google gerade für die Kombination Java – JavaScript entschieden hat, kann nur spekuliert werden. Wirft man aber beispielsweise einen Blick auf Abbildung 1-1, dann wird deutlich, dass beide Sprachen sehr weit verbreitet sind (für diese Grafik wurden die Buchverkäufe ausgewertet). Etwa 25% der verkauften Bücher befassen sich mit diesen beiden Sprachen. Daraus kann eine sehr breite Anwenderbasis abgeleitet werden. Die Prozentzahl in den Blöcken gibt an, wie groß die Veränderung gegenüber dem Vorjahr war. Am Zuwachs bei JavaScript um fast 50% dürfte der Ajax-Hype nicht ganz unschuldig sein. Abbildung 1-1: O’Reilly-Programmiersprachenindex, Stand 4. Quartal 2006 (Quelle: http://radar.oreilly.com/archives/2007/01/state_of_the_co_3.html) Der Google-Weg | 7 719-5.book Seite 8 Mittwoch, 9. Januar 2008 10:58 10 Besonders im kommerziellen Umfeld wird Java sehr häufig für die Implementierung der Serverlogik benutzt. Auch aus diesem Grund ist es sinnvoll, Java für die Entwicklung von Ajax-Anwendungen zu benutzen. Auf diese Weise können Entwickler von den Erfahrungen profitieren, die sie sowieso schon mit Java haben. Der Weg hin zu JavaScript über eine andere Sprache hat noch einen weiteren Vorteil. Die Sprachmittel von Java ermöglichen es, gegen Schnittstellen zu programmieren. Dadurch lassen sich Implementierungen austauschen. Gerade die vielen Browser-Inkompatibilitäten lassen sich so hervorragend verbergen. Man muss sich als Entwickler nicht darum kümmern, wie sich die Browser-Historie so verbiegen lässt, dass auch eine Ajax-Anwendung über die Vor- und Zurück-Buttons der Browser bedienbar wird. Das GWT-Prinzip Wenn man das Google Web Toolkit also für die Erstellung von Ajax-Webanwendungen einsetzt, dann programmiert man zunächst einmal in Java. Mit Hilfe des GWT-Compilers wird dieser Java-Quelltext dann nach JavaScript übersetzt. Nimmt man den JavaQuellcode für sich und verzichtet auf Oberflächenkomponenten und die direkte Integration von JavaScript (dazu später mehr), dann hat man aber auch Quellcode vor sich, der in jeder Java Virtual Machine lauffähig ist. Man kann den gleichen Quellcode zumindest theoretisch auf dem Server und im Client verwenden. Zur Laufzeit ist es im Client dann aber JavaScript. Wie wir noch sehen werden, ist das GWT auch in der Lage, für jeden Browser eine eigene JavaScript-Datei zu erstellen. Dieses so genannte Deferred Binding ermöglicht es, den zu ladenden Quellcode deutlich zu reduzieren. Andernfalls müsste jeder Browser auch Quellcode laden, der gar nicht für ihn bestimmt ist. Das Prinzip wird auch benutzt, um verschiedene Landessprachen einer Ajax-Anwendung zu unterstützen. Auch hier gilt: Es werden nur die Sprachinformationen geladen, die letztendlich auch zur Anzeige kommen. In die HTML-Seite muss die so erstellte JavaScript-Datei dann nur noch eingebunden werden – den Rest erledigt das kompilierte JavaScript. Dass eine Webseite überhaupt mit Hilfe des GWT umgesetzt wurde, erkennt man nur, wenn man diese JavaScript-Datei analysiert. Andere Hinweise gibt es nicht. Wer setzt das GWT ein? Etwa ein Jahr nach der Veröffentlichung des Toolkits durch Google wurde im Mai 2007 der millionste Download gezählt. Das Entwicklerforum (http://groups.google.com/ group/Google-Web-Toolkit) hat inzwischen über 9.000 Mitglieder und weist zum heutigen Zeitpunkt (September 2007) einen Umfang von mehr als 30.000 Beiträgen auf. Da man einer Webanwendung von außen nicht unbedingt ansieht, dass sie mit dem Google Web Toolkit umgesetzt wurde, ist es etwas schwierig herauszubekommen, wer das Toolkit für produktive Anwendungen einsetzt. In der Regel erfährt man das nur durch entsprechende Werbung der Unternehmen oder durch Forenbeiträge. 8 | Kapitel 1: Einleitung 719-5.book Seite 9 Mittwoch, 9. Januar 2008 10:58 10 Hier einige Beispiele: • www.eTripBuilder.com – ein Reiseplaner, vollständig mit dem GWT realisiert. • http://tellmewhere.com/ – eine typische Web 2.0-Anwendung, in der man seine Lieblingsorte anderen mitteilen kann. • http://openkm.com/index.pl/home_en – ein OpenSource-Dokumentenmanagement. • http://beta.contactoffice.com/ – eine Anwendung für Bürosoftware. • Ich verwende das Toolkit jetzt seit über einem Jahr für unterschiedliche Projekte: z.B. auf www.epivista.de, das auch Ausgangsbasis für das Beispiel in diesem Buch war. Google scheint sich momentan noch zurückzuhalten, was den Einsatz des Toolkits für die eigenen zahlreichen Ajax-Anwendungen angeht. Es gibt inzwischen auch eine sehr große Anzahl an Bibliotheken, die das GWT um Oberflächenkomponenten erweitern. Auch Werkzeuge zum Erstellen von Oberflächen sind inzwischen verfügbar. Für welche Projekte eignet sich das GWT, für welche eher nicht? Grundsätzlich lässt sich fast jede Form von Webanwendung mit dem Google Web Toolkit umsetzen. Wirklich sinnvoll ist der Einsatz aber nur dann, wenn es sich um hochdynamische Anwendungen handelt, die besonders viel Benutzerinteraktion erfordern. Das können typische Office-Anwendungen oder solche Anwendungen sein, bei denen der Anwender sehr viele Daten erfassen muss. Bei dem Beispiel zu diesem Buch ist das der Fall. Von Vorteil ist das GWT besonders, wenn auch die serverseitige Entwicklung bereits in Java erfolgt. Dann ist nämlich das nötige Know-how für einen sehr schnellen Ein-/ Umstieg bereits vorhanden. Nichtsdestotrotz lässt es sich aber auch für Anwendungen benutzen, die auf PHP oder einer anderen Sprache für die Erstellung dynamischer Webanwendungen basieren. Eher ungeeignet ist das GWT, wenn es ausschließlich darum geht, eine Seite mit den weitverbreiteten optischen Effekten zu versehen. Dazu gibt es zahlreiche JavaScriptBibliotheken, die sich genau an diese Zielgruppe wenden. Außer Acht lassen sollte man auch nicht, dass es viele Anwendungsgebiete gibt, die sehr hohe Anforderungen an die Sicherheit einer Webanwendung stellen. Da kann es durchaus eine Forderung geben, dass JavaScript nicht verwendet werden darf. Somit ist auch das GWT nicht einsetzbar. Auf diese Problematik werde ich in Kapitel 6 ausführlicher eingehen. Der Google-Weg | 9 719-5.book Seite 10 Mittwoch, 9. Januar 2008 10:58 10 Ausblick Momentan (September 2007) ist die Version 1.4 des GWT aktuell. Diese Version ist auch die Grundlage für dieses Buch. An einigen Stellen werde ich auf besondere Änderungen und Erweiterungen im Vergleich zur Version 1.3 hinweisen. Zu Beginn der Entwicklung waren der Quellcode des Compilers und der GWT-Shell nicht öffentlich verfügbar. Inzwischen ist das Google Web Toolkit vollständig Open Source. Ein sehr zu begrüßender Schritt. Trotzdem stellt sich natürlich die Frage, warum Google ein solches Toolkit vollständig öffentlich macht. Das dürfte mit der strategischen Zielsetzung von Google zu tun haben: Wenn es das Ziel ist, herkömmliche DesktopAnwendungen durch Webanwendungen zu ersetzen (eine klare Kampfansage an Microsoft), dann muss die Entwicklung solcher Anwendungen einfach und kostengünstig möglich sein. Und genau das ist mit dem Google Web Toolkit möglich. Auch in Kombination mit Google Gears – einer Browser-Erweiterung, um Webanwendungen mit der Möglichkeit zu versehen, offline zu arbeiten – ergeben sich völlig neue Einsatzmöglichkeiten für dieses Toolkit. Insofern ist die Investition in GWT-Know-how also keine vertane Zeit! Über dieses Buch In diesem Buch geht es nicht darum, jedes Feature des Google Web Toolkits vorzustellen und in ausführlichen Beispielen durchzuexerzieren. Ziel ist es, Ihnen ein Hilfsmittel für die Erstellung professioneller Lösungen auf Basis dieses Toolkits an die Hand zu geben. Dazu zählt es, die Arbeitsweise des Toolkits zu verstehen und die richtigen Design-Entscheidungen zu treffen. Zielgruppe und Voraussetzungen Das Buch wendet sich daher an Webentwickler, die bereits Erfahrungen mit Java haben. Außerdem sind grundlegende Kenntnisse über HTML, DOM, JavaScript, CSS – also die Basis jeder Webanwendung – zwingend erforderlich. Für Einsteiger in die Materie Ajax und Web ist es eher ungeeignet. Für Entwickler, die noch nie mit Java in Berührung gekommen sind, wird die Lektüre unter Umständen schwierig sein – allerdings muss auch niemand ein Java-Profi sein. Von Vorteil ist es auch, wenn einige Grundkenntnisse auf dem Gebiet der objektorientierten Entwurfsmuster vorhanden sind. Das Beispiel Die Kapitel enthalten für die einzelnen Themen eine allgemeine Beschreibung, bieten als »Gedankenstütze« aber auch immer eine ganz konkrete Lösung. Am Ende des Buches werden die Bausteine für ein vollständiges Fitnesstagebuch zusammengetragen sein, das Sie auch live unter http://www.gwt-buch.de/fitnesstagebuch ausprobieren können. 10 | Kapitel 1: Einleitung 719-5.book Seite 11 Mittwoch, 9. Januar 2008 10:58 10 Dieses Fitnesstagebuch ermöglicht dem Anwender, seine sportlichen Aktivitäten in einer Drei-Monats-Übersicht zu planen und zu dokumentieren. Er kann sich sämtliche Sportarten, Trainingsarten, Strecken und die verwendete Ausrüstung frei konfigurieren. Die zurückgelegten Strecken werden für jeden Monat aufsummiert. Durch die Möglichkeit, Einträge zu kopieren, auszuschneiden und einzufügen, lässt sich die Anwendung mit einer Geschwindigkeit bedienen, wie Sie sie sicherlich nur von Desktop-Anwendungen gewohnt sind. Für Auswertungen lassen sich die Daten als Excel-Datei herunterladen. Abbildung 1-2: Das Fitnesstagebuch Abbildung 1-2 zeigt den derzeitigen Stand (September 2007). Wenn Sie das Buch in den Händen halten, wird sich der Funktionsumfang vielleicht noch etwas erhöht haben – mit dem GWT zu arbeiten macht nämlich auch Spaß. Der Quelltext ist teilweise auf der Homepage zum Buch verfügbar. Bei Interesse am gesamten Projekt schreiben Sie mir einfach. Über dieses Buch | 11 719-5.book Seite 12 Mittwoch, 9. Januar 2008 10:58 10 Aufbau des Buches Im folgenden Kapitel werde ich Ihnen das Google Web Toolkit vorstellen. Ich werde die Prinzipien erläutern und anhand kurzer Beispiele die Verwendung demonstrieren. Wenn Sie mit dem GWT bereits vertraut sind, können Sie dieses Kapitel getrost überspringen. Die dann folgenden Kapitel gehen in die Tiefe und befassen sich mit der konkreten Entwicklung von Ajax-Anwendungen. Dabei sind die Kapitel chronologisch aufgebaut. Am Anfang stehen die Architekturentscheidungen und das Einrichten der Entwicklungsumgebung. Danach folgen Themen wie Remote Procedure Call, Sitzungsverwaltung und objektorientiertes Programmieren von Oberflächen – Stichwort MVC. Wenn die Anwendung in den Grundzügen steht, werden wir uns der Lokalisierung und der Integration von JavaScript-Bibliotheken widmen. Abschließend werden das Deployment von GWTAnwendungen und die Performance-Optimierung behandelt. Damit entspricht die Reihenfolge der Kapitel etwa der Abfolge, die auch in einem realen Projekt abgearbeitet wird. Konventionen Ich werde durchgehend Eclipse als Entwicklungsumgebung benutzen. Zum einen, weil es inzwischen nahezu ein Standard ist, was gerade auf die Entwicklung mit Java zutrifft, und zum anderen, weil es auch meine bevorzugte IDE ist. Außerdem wird Eclipse vom Google Web Toolkit direkt unterstützt. Die dargestellten Prinzipien sollten so oder so ähnlich aber auch in anderen Entwicklungsumgebungen verfügbar sein. Da das GWT momentan nur mit der Java-Version 1.4 arbeitet – um genau zu sein: nur Java 1.4-Quellcode lässt sich nach JavaScript übersetzen –, werde ich durchgehend diese Java-Version verwenden. Das gilt auch für Quellcode, der serverseitig eingesetzt wird. In der Version 1.5 des GWT wird es die Beschränkung auf Java 1.4 aber nicht mehr geben, so dass dann beispielsweise auch Generics, Annotations und Enums für die Entwicklung benutzt werden können. Einige Grafiken enthalten »Pseudo-UML-Diagramme«. Die Grafiken sind allerdings stark reduziert. Eigentlich genügt es zu wissen, dass ein Pfeil eine Ableitung meint und ein gestrichelter Pfeil andeutet, dass die Klasse ein Interface implementiert. Alles andere dürfte sich aus dem Zusammenhang erschließen. Ich werde mich bemühen, soweit möglich und sinnvoll, die deutsche Sprache zu verwenden. An einigen Stellen geht das aber nicht. Zum Beispiel dann, wenn Fachbegriffe und Eigennamen aus der Java- oder GWT-Welt benutzt werden, für die es keinen deutschen Begriff gibt. Diese werde ich nicht übersetzen, damit Sie die gleichen Begriffe auch in englischsprachigen Dokumentationen wiederfinden. Auch die verwendete Eclipse-Version ist englisch. Sicher gibt es auch deutsche Sprachpakete für Eclipse, die aber nur selten verwendet werden und im Allgemeinen nicht vollständig sind, so dass es wahrscheinlich dazu kommen würde, dass einige Eclipse-spezifische Begriffe englisch und andere in Deutsch erscheinen. 12 | Kapitel 1: Einleitung 719-5.book Seite 13 Mittwoch, 9. Januar 2008 10:58 10 Dieses Buch verwendet außerdem die folgenden typografischen Konventionen: Kursiv Wird für wichtige Begriffe, Programm- und Dateinamen, URLs, Ordner und Verzeichnispfade und zur Hervorhebung verwendet. Nichtproportionalschrift Wird für Programmcode, Klassen- und Methodennamen verwendet. Fette Nichtproportionalschrift Verwende ich, um wichtige Stellen im Code herauszustellen, auf die ich mich im erläuternden Fließtext beziehe. KAPITÄLCHEN Kennzeichnen Menüeinträge, Buttons und andere GUI-Schaltflächen. Dies ist ein praktischer Hinweis darauf, wie Sie Dinge einfacher und schneller durchführen können. Mit diesem Symbol wird auf Besonderheiten hingewiesen, die zu Problemen führen oder ein Risiko darstellen knnen. Über dieses Buch | 13 719-5.book Seite 14 Mittwoch, 9. Januar 2008 10:58 10 719-5.book Seite 15 Mittwoch, 9. Januar 2008 10:58 10 KAPITEL 2 Das Google Web Toolkit – eine Rundreise In diesem Kapitel werde ich Ihnen das Google Web Toolkit und die grundsätzliche Arbeitsweise mit dem Toolkit vorstellen. Dabei ist es nicht das Ziel, jedes Feature ausführlich darzustellen, sondern Ihnen einen Überblick zu verschaffen. Wenn Sie mit dem Toolkit bereits vertraut sind, können Sie dieses Kapitel getrost überspringen. Download und Installation Alles, was Sie zum Arbeiten benötigen, ist das Toolkit, das Sie auf der Homepage (http://code.google.com/webtoolkit/) herunterladen können, und ein Java Runtime Environment ab Version 1.4. Nach dem Entpacken des Toolkits in das Dateisystem befinden sich dort einige Jar-Dateien, DLLs (bei der Windows-Version), so-Dateien (bei der Linux-Version) bzw. jnilib-Dateien (bei der Mac-Version). Außerdem finden Sie dort die Dokumentation, einige Beispiele und ein paar Batch-Dateien, die den Aufruf der Kommandozeilenwerkzeuge etwas komfortabler machen. Dieses Verzeichnis werde ich in Zukunft als GWT-Home bezeichnen. Das Google Web Toolkit ist also zunächst einmal nichts weiter als eine Sammlung von Bibliotheken und einigen Kommandozeilenwerkzeugen. Diese Werkzeuge stellen auch nichts weiter dar als einen komfortableren Weg, die main-Methoden von Java-Klassen des GWT aufzurufen. Da das Toolkit in Java geschrieben ist, lässt es sich zudem sehr gut in jede Java-Entwicklungsumgebung integrieren. Arbeitsprinzip Wenn man eine Webanwendung mit Hilfe des Google Web Toolkits erstellen möchte, programmiert man gegen ein Java-API, das vom GWT zur Verfügung gestellt wird. Der eigene Quellcode wird mit Hilfe des GWT-Compilers nach JavaScript übersetzt. Die Packages java.lang und java.util werden dabei emuliert. Für das Ausführen einer mit dem GWT erstellten Webanwendung benötigt man daher später so gut wie keine Bibliotheken des GWT. Im Browser des Benutzers läuft die Anwendung völlig in JavaScript. | 15 719-5.book Seite 16 Mittwoch, 9. Januar 2008 10:58 10 Nur auf dem Server wird eine Bibliothek des GWT benötigt, wenn man den Remote Procedure Call-Mechanismus des GWT verwendet – das muss aber nicht zwingend der Fall sein. Durch die GWT-Shell wird der Entwickler bei der Umsetzung von GWT-Anwendungen unterstützt. Sie stellt eine Ablaufumgebung dar, in der die spätere Anwendung ohne ein Kompilieren nach JavaScript ausgeführt werden kann. Dazu bildet sie eine »Schale« um einen Browser (Internet Explorer unter Windows und Firefox unter Linux). So ermöglicht das GWT auch das Debuggen einer Webanwendung, die später in JavaScript ablaufen wird. Das Google Web Toolkit setzt sich aus folgenden Bestandteilen zusammen: • der GWT-Shell (mit einem integrierten Tomcat) – als Entwicklungswerkzeug • dem GWT-Compiler – zur Übersetzung des Java-Quellcodes nach JavaScript • dem GWT-API, gegen das wir die Webanwendung programmieren Projekt generieren Wenn man sich einem unbekannten Werkzeug oder einer neuen Programmiersprache nähert, war es schon immer ein bewährtes Vorgehen, mit einem Hallo-Welt-Beispiel zu beginnen. Das Google Web Toolkit macht es uns in dieser Hinsicht sehr einfach, weil das generierte Grundgerüst eines GWT-Projekts schon ein solches Beispiel ist. Um ein neues GWT-Projekt für die Eclipse-Entwicklungsumgebung zu erstellen, enthält das Toolkit zwei Kommandozeilenwerkzeuge, die ein Grundgerüst der Anwendung generieren können. Dabei ist projectCreator für das Erstellen eines nahezu leeren Eclipse-Projekts verantwortlich und applicationCreator für die eigentlichen Projektquellen. Das Eclipse-Projekt kann über den folgenden Befehl auf der Kommandozeile erstellt werden: projectCreator -eclipse HalloWelt -out HalloWelt Dazu kann man in das GWT-Home-Verzeichnis wechseln oder das GWT-Home-Verzeichnis der PATH-Variable hinzufügen, um den Befehl aus einem beliebigen Verzeichnis heraus aufzurufen. Im Ergebnis wird das Verzeichnis HalloWelt angelegt, und darin werden die beiden Verzeichnisse src und test erstellt. Außerdem werden die Dateien .classpath und .project erstellt, die die Eclipse-Umgebung konfigurieren. Das generierte Eclipse-Projekt erhält den Namen HalloWelt, wie von uns durch den Wert des Parameters –eclipse vorgegeben. Als Nächstes werden die eigentlichen Java-Quellen mit dem folgenden Aufruf generiert: applicationCreator -eclipse HalloWelt -out HalloWelt de.gwtbuch.client.HalloWelt Auch hier müssen wiederum der Name des Eclipse-Projekts und das Ausgabeverzeichnis angegeben werden. Zusätzlich wird der Name des zu erstellenden GWT-Moduls übergeben. Dieses muss im Package-Namen zwingend client enthalten. 16 | Kapitel 2: Das Google Web Toolkit – eine Rundreise 719-5.book Seite 17 Mittwoch, 9. Januar 2008 10:58 10 Das so generierte Projekt kann jetzt in Eclipse importiert werden. Dazu wird der Menüpunkt IMPORT (Kontextmenü oder Menü FILE) benutzt und im dann erscheinenden Dialog die Option »Existing Projects into Workspace« ausgewählt. Anschließend muss nur noch das Verzeichnis HalloWelt angegeben werden. Das Projekt HalloWelt wählt Eclipse automatisch aus. Die Projektstruktur Nach dem erfolgreichen Import des Projektes ist die in Abbildung 2-1 sichtbare Projektstruktur in Eclipse verfügbar. Abbildung 2-1: Die Standard-Projektstruktur in Eclipse Die beiden Batch-Dateien HalloWelt-compile und HalloWelt-shell kann man löschen, da sie für erste Tests mit der Eclipse-Entwicklungsumgebung nicht erforderlich sind und ich in späteren Kapiteln noch zeigen werde, dass man ganz gut ohne sie auskommt. Wer Eclipse nicht benutzt, ist aber auf diese beiden Befehle angewiesen. Damit lässt sich nämlich die GWT-Shell starten und das Projekt nach JavaScript kompilieren. In der Datei HalloWelt.launch speichert Eclipse die Run-Konfiguration für das Ausführen der GWT-Shell. Diese Datei ist dafür verantwortlich, dass sich bereits nach dem Import ein Eintrag HALLOWELT im Dialog für die Run-Konfigurationen befindet. Diesen muss man nur auswählen, und die Shell wird gestartet. Alle nötigen Einstellungen, wie der Classpath, die Parameter und die auszuführende Klasse, sind bereits automatisch eingetragen. Wird die Run-Konfiguration ausgeführt, startet die GWT-Shell und öffnet den Hosted-Browser. Die Projektstruktur | 17
