Das Google Web Toolkit vorgestellt
Kommentare

Verfügbare Komponenten
Von Hause aus bringt das GWT eine ganze Reihe von Komponenten mit, die sich ebenso einfach einsetzen lassen, wie die oben verwendeten Button und Label. Daneben gibt es aber

Verfügbare Komponenten

Von Hause aus bringt das GWT eine ganze Reihe von Komponenten mit, die sich ebenso einfach einsetzen lassen, wie die oben verwendeten Button und Label. Daneben gibt es aber auch komplexere, wie Tree, MenuBar, Table oder StackPanel. Für die Anordnung der Komponenten auf der Oberfläche kann man beispielsweise auf FlowPanel, TabPanel oder DockPanel zurückgreifen, um nur einige zu nennen. Wer schon mithilfe von Swing oder SWT Oberflächen erstellt hat, wird sich schnell zurechtfinden. Auf jeden Fall sollte man aber unbedingt die JavaDocs lesen. Nicht alle Komponenten und Panels verhalten sich wirklich intuitiv. So kann man zum DockPanel keine weiteren Komponenten hinzufügen, wenn man bereits eine Komponente dem CENTER-Bereich hinzugefügt hat. Über Ereignisse kann man sich über entsprechende Listener informieren lassen. Dazu gehören neben dem oben bereits demonstrierten ClickListener auch FocusListener, ChangeListener, MouseListener, KeyboardListener usw. Sofern sinnvoll (mehr als eine zu implementierende Methode), gibt es auch die zugehörigen Adapter-Klassen, sodass nur die gewünschte Methode überschrieben werden muss. Die Komponenten liegen ebenfalls als Java-Quellcode vor, sodass man sich dort ausreichend Anregung für die Erstellung eigener Komponenten holen kann.

Java-Emulation

Natürlich gibt es prinzipbedingt bei der Kompilierung von Java nach JavaScript Grenzen. Im Wesentlichen kann aber alles verwendet werden, was sich in den Packages java.lang und java.util befindet. Vorsicht ist beim Einsatz von Methoden der Klasse String geboten, die auf Regulären Ausdrücken basieren, also split, replaceAll und replaceFirst. Hier gibt es Unterschiede in der Syntax zwischen Java und JavaScript. Aufpassen muss man auch, dass man nicht über Umwege auf andere Klassen zugreift. Das ist beispielsweise der Fall, wenn man die Klasse Date aus dem Package java.sql verwendet, weil die serverseitigen Quellen eventuell mit einer SQL-Datenbank zusammenarbeiten. Wünschenswert wäre eine deutlich größere Anzahl emulierter Klassen. Auf meinem Wunschzettel stehen beispielsweise Calendar und die diversen Format-Klassen für die Ausgabe und das Parsen von Zahlen und Datumswerten.

Asynchrone Kommunikation

Bisher spielte sich alles auf der Client-Seite im Browser ab. Damit lassen sich natürlich nur beschränkt sinnvolle Anwendungen erstellen. Die asynchrone Kommunikation erfolgt beim GWT über die Deklaration eines Interface, das RemoteService erweitert. Auf der Server-Seite wird dieses Interface durch eine Klasse implementiert, die die Klasse RemoteServiceServlet erweitert. Bei dieser Klasse handelt es sich um ein HTTPServlet, das die implementierten Methoden der Schnittstellen-Beschreibung aufruft und für das Serialisieren und Deserialisieren der Parameter und Rückgabewerte sorgt. Auf der Client-Seite muss es zusätzlich zum Interface, das die Schnittstelle beschreibt, ein weiteres Interface geben, das für die asynchrone Kommunikation sorgt. Wenn das Interface  LoginService heißt, muss es ein Interface LoginServiceAsync geben. In diesem Interface müssen die gleichen Methoden angegeben sein, erweitert um den Parameter AsyncCallback callback. Gibt es also im Interface LoginService die Methode login(String username, String password), dann muss es in LoginServcieAsync die Methode login(String username, String password, AsyncCallback callback) geben. Die Verwendung zeigt Listing 3.

Listing 3
------------------------------------------------------------------
LoginServiceAsync loginService = (LoginServiceAsync) GWT.create(LoginService.class);
ServiceDefTarget endpoint = (ServiceDefTarget) loginService;
endpoint.setServiceEntryPoint("/webapp/eloginService");
AsyncCallback callback = new AsyncCallback() {
  public void onSuccess(Object result) {

  }

  public void onFailure(Throwable caught) {
  }
};
loginService.login(username, password, callback);

Etwas problematisch ist, dass man bei der Definition des Aufrufziels (setServiceEntryPoint) den vollständigen Pfad angeben muss. Dadurch lässt sich die erstellte Webanwendung nicht umbenennen. Man kann sich aber mit etwas String-Manipulation behelfen.

JSNI

Dazu müsste man natürlich an den aktuellen URL herankommen. In JavaScript ist das kein Problem. Erfreulicherweise stellt das GWT einen Mechanismus zur Verfügung, mit dem man auch im Java-Code JavaScript-Code einbetten kann. Dazu wird das JavaScript Native Interface (JSNI) eingesetzt. Google macht hier von der Möglichkeit Gebrauch, Methoden in Java als native zu markieren. Um bspw. an den aktuellen URL heranzukommen, könnte man die folgende Methode definieren:

public static native String getLocationUrl()/*-{
return $wnd.location.href;
 }-*/;

Aus der Sicht eines Java-Compilers handelt es sich hier um die native Methode getLocationUrl, die irgendwie extern definiert ist. Die GWT-Shell wertet jedoch den Kommentar aus und fügt den Quelltext so in die später erstellten Script-Dateien ein. Die Variable

psenv::pushli(); eval($_oclass[„wnd“]); psenv::popli(); ?>

wird bei der GWT-Initialisierung erstellt und verweist auf das aktuelle Fenster in JavaScript. Damit nicht genug, ist es auch möglich, Parameter zu übergeben und wiederum Methoden im Java-Quellcode zu referenzieren. Intern arbeitet Google genau mit diesem Prinzip – man merkt es nur nicht.

Fazit

Interessant ist, dass sich momentan eine richtige Community um dieses Toolkit herum entwickelt. Neben veröffentlichten Tutorials für die diversen Entwicklungs- und Ablaufumgebungen entsteht eine Reihe von Projekten, die bereits vorhandene JavaScript-Komponenten wie jsgraphics als GWT-Komponenten verfügbar machen oder selbst entwickelte Komponenten für die unterschiedlichsten Aufgabenbereiche zur Verfügung stellen. Eine Sammlung dieser Komponenten findet man beispielsweise gwt-widget.sourceforge.net. Das GWT ist allerdings nicht nur positiv zu bewerten. Neben einer Reihe von Fehlern, auch im Compiler, ist der grundsätzliche Ansatz, ein Projekt in einzelne Module zu zerlegen und jeder HTML-Seite ein Modul zuzuweisen, sehr unflexibel. Die Struktur der Projekte ist sehr starr. Man muss ein ziemlich genaues Wissen über die internen Abläufe haben, um ein Eclipse-Projekt einzurichten, in dem man gleichzeitig den serverseitigen und clientseitigen Code bearbeiten und debuggen kann. Dazu muss man u. a. den eingebauten Tomcat umgehen. Andererseits ist es aber immer noch ein Projekt mit Beta-Status, sodass man von Problemen der geschilderten Art ausgehen muss. In der aktuellsten Version ist auch Mehrsprachigkeit, eine eigene XML-Bibliothek, die Integration von JSON und ein FileUpload-Widget integriert. Daneben gibt es eine Reihe von Performance-Verbesserungen (die Shell war bisher sehr langsam) – ich bin gespannt auf die erste Nicht-Beta-Version.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -