30 minütige Präsentation des Google Web Toolkit, einem Java Framework zum erstennellen von Javafreien-Web-Applikationen. Den Download des Beispielprogramms finden Sie auf http://www.easy-coding.de/trac/gwt .

1. GWT
Google Web Toolkit
Referent: Torben Brodt
Veranstaltung: Fachseminar Webframeworks
Datum: 20.12.2007

2. Hello World!

Das klassische Codebeispiel

3. Java, Java, Java!

Programmieren in Java

Ausführen in Java

Testen in Java

Debuggen in Java

Verteilen in JavaScript !

4. Inhaltsverzeichnis
1. Der GWT Weg
2. Tools
●
Compiler, Hosted Browser, Framework
3. Vorteile des Paradigmas
4. Features + Demo + Coding
5. Fragen

5. Der GWT Weg

System­Sprache statt Auszeichnungssprache

GWT­ statt Swing­Klassen, aber Handling gleich

Der Code bleibt für Browser und Menschen lesbar

Programmiert wird in Systemsprache, wegen...

der riesigen Toolunterstützung

der Java Spracheigenschaften

Übersichtlichkeit trotz komplexer Systeme

6. Der GWT Weg

Ergebnis = kein Java, kein Applet, keine VM

einzige Voraussetzung: Browser

anderer Weg für selbes Ergebnis

JavaScript und Java sind zwar syntaktisch ähnlich,
aber bei dem Konzept hätte Google jede andere
Sprache wählen können (siehe Projekt: pyjamas)

Ähnlich Swing, aber kein SWING

Anwendung muss neu erstellt werden

7. Der Compiler

Code Compiler

erstellt eine statische HTML Datei als Container

pro Browser/Sprachkombination ein JavaScript
compilieren

nur verwendete Frameworkteile werden mitgeliefert

8. Der Compiler

Bild Compiler – die Problemstellung

herkömmlich führt jedes Bild zu einer HTTP
Abfrage
GET dateiname.png
200 OK

9. Der Compiler

Bild Compiler – die Lösung

mehrere Bilder werden zu einem ImageBundle

gleiche Dateigröße und dabei weniger HTTP
Requests
GET dateiname.png

10. Der Compiler

ImageBundles werden als Interfaces geschrieben

Will man Bilder nicht zentral verwalten, fasst man sie
durch ”ableiten” zusammen

Einbinden per HTML oder ImageProto

11. Der Compiler

ImageBundles werden als Interfaces geschrieben

Will man Bilder nicht zentral verwalten, fasst man sie
durch ”ableiten” zusammen

Einbinden per HTML oder ImageProto

12. Hosted Mode

Refresh synchronisiert mit Java­Code

Emuliert einen Browser

Oberfläche zum Exportieren in ”Web Mode”

13. Framework

java.lang und java.util sind nachimplementiert

Bedienelemente (Widgets) sind vorhanden

Vorteil durch Abstraktion

Das Web ist ein schnell mutierendes Umfeld

Viele Problemlösungen will man in 3 Monaten ganz
anders machen

Da man weit weg vom JavaScript Code ist, reicht
eine aktualisierte GWT.jar

14. Vorteile des Paradigmas

GWT ändert das Paradigma. Erstmals Typisierung
und Möglichkeiten zum Debuggen + Refactoren

15. Vorteile des Paradigmas

Beliebige Java IDE, da Einbindung per .jar

GWT ist zwar allein zur Frontendprogrammierung..
bringt aber dennoch einen Tomcat Server zur
Abrundung mit

Start per Button

Aktualisieren durch Browser Refresh

Vollständiges Debuggen möglich

Teamaufteilung ist besser möglich

16. Features
1.Bessere HTTP­Performance durch Verwendung von
ImageBundles und smarter Dateien
2.Programmiersprache für zeitgerechtes Programmieren
3.Gestaltungs­ und Bedienelemente
4.Realisierbare Usability
5.AJAX durch Remote Procedure Calls
6.Internationalisierung
7.Testing und Benchmarking

17. Gestaltungs­ und Bedienelemente

Panel für Widgets oder weitere Panels

ähnlich AWT/Swing Konzept in Java
TabPanel Horizontal­
SplitPanel

18. Gestaltungs­ und Bedienelemente

Widgets für Benutzerinteraktionen

Normale Formular­Elemente

Button, RadioButton, CheckBox, TextBox,
PasswordTextBox, TextArea, ListBox

Formularfreie Interaktionselemente

Hyperlink, HTML

Weitere Elemente aus Desktopwelt

19. Gestaltungs­ und Bedienelemente

Mail­Beispielclient.... erweitert :­)

20. Realisierbare Usability

Einfache Implementierung von Browserhistory
... und Bookmarkfunktionalität

21. Realisierbare Usability

Implementierung durch zentralen Controller, der URL
Parameter durchreicht

Implementierung von HistoryListener

22. Remote Procedure Calls

MailService (Interface)

Beschreibt das tatsächliche Aussehen

Wird vom Backend implementiert

23. Remote Procedure Calls

MailServiceAsync (Interface)

AJAX Implementierung (typisch void)

Wird vom Frontend implementiert

24. Remote Procedure Calls

emailService Proxy

25. Remote Procedure Calls

Backend

implementiert die Methoden von MailService

komplexe Datentypen erlaubt
Frontend Backend

26. Internationalisierung

Statische VS dynamische Internationalisierung

Statische bevorzugt, da neben Sprache auch
Eigenschaften (Zeit­ und Zahlenformate)
einfacher umgestellt werden können

Auswahl entweder automatisch, über URL oder
per Methodenaufruf

27. Internationalisierung

Mail.gwt.xml um Sprachmodul erweitern

Klasse implementieren (und instanziieren)

Property­Dateien anlegen

Mailboxes$Language.properties bzw ..._de.properties

28. Internationalisierung

Beispiel einer Property Datei
compose = Neu
sync = Verschicken/Abrufen!
reply = Antworten

Sprachvariablen austauschen

29. Wiederverwendung

alter JavaScript Code kann wiederverwendet werden

durch das Schlüsselwort native

Zugriff zurück auf Java durch spezielle Syntax

Arbeit mit window und document über $wnd und $doc

30. Testing & Benchmarking

JUNIT Integration in GWT über eigene Klasse

asynchrones Testen von Front­ bis Backend
durch Simulation von Verzögerung

Realisierung über versteckten GWT Browser

GUI­Erweiterung für Benchmarking

31. Fragen

Fragen?