JavaScript fuer Eclipse-Entwickler

zu erhöhen, würde nur gleichzeitig auch die Last auf dem Server beachtlich erhöhen, ohne das Problem wirklich zu lösen. Außerdem müssten die Browser entsprechend konfiguriert werden, was nicht immer einfach oder gar möglich ist. Die Lösung des Problems liegt darin, die Anzahl der notwendigen Verbindungen prinzipiell zu reduzieren. Das Single-Page-Prinzip sorgt schon mal dafür, dass die Anwendung lediglich einmal geladen wird, und somit führt nicht jede Benutzeraktion auf der Webseite zu einem kompletten Neuladen und Rendern der Seite. Des Weiteren können sowohl CSS als auch JavaScript in die geladene HTML-Host-Seite eingebettet und statische Bilder zu einem Mosaik zusammengefasst (und clientseitig per CSS Clipping angezeigt) werden. Zudem besteht zusätzlich die Möglichkeit, Bilder Base64-kodiert ebenfalls in die HTML-Seite einzubetten.
    Das Toolkit liefert einen Java-zu-JavaScript-Compiler, der mehr als die eigentliche Übersetzung durchführen kann. Neben der eigentlichen Transformation ist GWT zudem in der Lage, unter anderem die oben genannten Optimierungen vorzunehmen. Der generierte JavaScript-Code kann außerdem je nach Konfiguration zum Beispiel in einer knappen Form (obfuscated) erzeugt werden. Es werden mehrere Permutationen der Anwendung generiert, für jede Sprache und jeden Browser, damit dem Anwender das Laden und Ausführen von unnötigem Anwendungscode erspart bleibt. Dem Toolkit merkt man sehr schnell an, dass es nicht nur Produktionsreife hat, sondern auch tatsächlich produktiv (von Google) eingesetzt wird. So werden zum Beispiel die generierten Dateien mit (sehr) eindeutigen Namen versehen. Dank des „cache“ oder „nocache“ im Namen können Filterregeln im Webserver erstellt werden, durch die entsprechende HTTP Header für das richtige Cacheverhalten im Browser sorgen. Die Art und Weise (Umfang und Konsequenz) mit der Optimierungen am Compiler, Internationalisierungskonzepte, Compilerberichte und vieles mehr. umgesetzt werden zeigen, dass GWT für den produktiven Einsatz entwickelt wird.
    Das Google Web Toolkit definiert ein eigenes Modulkonzept. Module können andere Module erben und können fachlich sowohl Teile einer Anwendung als auch einzelne Komponenten beinhalten. Die Flexibilität in der Gestaltung der Granularität der GWT-Module ermöglicht die Konzeption und Realisierung eigener, anwendungsspezifischer Bedürfnisse. Allerdings handelt es sich um ein Modularisierungskonzept, das allein zur Compilezeit zum Tragen kommt. Das Toolkit selber besteht aus Modulen und Modulvererbungen.
    Besonders interessant sind auch die Erweiterungsmöglichkeiten, die angeboten werden. Da das UI-Komponentenmodell das Composite Pattern umsetzt, ist die Erstellung komplexer, wiederverwendbarer fachlicher Komponenten sehr einfach. Die Implementierung projektspezifischer Widgets ist auch sehr einfach. Der vom Compiler eingesetzte Mechanismus, Klassen spezifisch für die einzelnen Permutationen auszutauschen beziehungsweise die Möglichkeit, Codegeneratoren einzubinden, kann auch in eigenen Projekten verwendet werden. Die Anbindung von bereits existierendem JavaScript-Code in die eigene Anwendung ist sehr elegant umgesetzt worden: Aus dem in Java vorhandenen Konzept des Java Native Interface (JNI) wurde JavaScript Native Interface (JSNI), ein einfacher Weg, nativen JavaScript direkt in der Java-Klasse einzubinden. So werden beispielsweise Aufrufe von Fremdbibliotheken ermöglicht. Prominentes Beispiel an dieser Stelle ist die Brücke von GWT zu Google Maps: Es werden Java-Klassen bereitgestellt, die das Google Maps API kapseln.

4.1 Architektur?
    Die Entwicklung einer JavaScript-basierten RIA stellt die Webanwendungsentwicklung vor neue Anforderungen. Bekannte Ansätze verlieren ihre Gültigkeit, alte Entwurfsmuster werden wieder eingesetzt. In der klassischen Request-Response-basierten Webanwendungsentwicklung sind verschiedene Lösungsansätze für das Problem der Seitennavigation entwickelt worden, ein Problem das RIAs so nicht kennen. Andererseits dürfen sich RIA-Anwendungen ebenso wie Rich-Clients mit dem Problem des Datentransfers zwischen Client und Server auseinandersetzen, ein Problem, das wiederum Technologien, die serverseitig arbeiten, geschickt gelöst haben: Mit ORM-Tools, verschiedenen Frameworks, Lazy Loading, einer handvoll Best Practices, Tooling und Industrieunterstützung haben sich sehenswerte Lösungsansätze etabliert. Die meisten Ansätze betreiben allerdings keine