HTML and CSS Reference
In-Depth Information
4.2 Der Ansatz
Die Webentwicklung mit GWT unterscheidet sich beachtlich von den bisher üblichen Vorgehenswei-
sen. Im Java-Umfeld haben sich zwei Arten der Entwicklung durchgesetzt: entweder IDE-basiert,
zum Beispiel mit Eclipse WTP und Plug-ins, oder Build-Tool-basiert, zum Beispiel mit Maven. Ge-
meinsam haben die Vorgehensweisen den Fokus auf das Deployment und Redeployment der An-
wendung, denn dynamische Webanwendungen in Java dürfen erst einmal paketiert und anschließend
„deployt“ werden. Je nach Toolkette kann an der einen oder anderen Stelle optimiert beziehungswei-
se abgekürzt werden, das Grundprinzip bleibt aber gleich.
Glücklicherweise können wir dank des „Java to JavaScript“-Ansatzes genau diejenigen Werkzeuge
und Methoden auch für die Webentwicklung einsetzen, die wir seit Jahren für die Qualitätssicherung
während der Java-Softwareentwicklung eingesetzt haben: Da GWT die Entwicklung der Webanwen-
dung in der Programmiersprache Java ermöglicht, sind keine neuen Entwicklungsumgebungen nö-
tig. Der Entwickler kann die bisher eingesetzte Java IDE weiterhin verwenden. Etablierte Konzepte,
Vorgehensweisen und Werkzeuge können weiterhin beziehungsweise zum ersten Mal auch für die
Webanwendungsentwicklung eigesetzt werden. PMD, FindBugs, Refactoring, etablierte Idiome und
Entwurfsmuster, der GWT-Ansatz macht es möglich.
Allerdings geht das Google-Team in Bezug auf den Entwicklungszyklus einen etwas anderen Weg.
Da es sich bei GWT nicht um eine dynamische Java EE wie aus dem Lehrbuch handelt, sind auch
Eclipse-Plug-ins aus dem Webumfeld kaum nützlich. So hat das Team ein eigenes Plug-in für Eclip-
se entwickelt, das eine nahtlose Integration der GWT-Entwicklung in Eclipse ermöglicht. Das Goo-
gle Plug-in for Eclipse, kurz GPE [1], nutzt neben GWT auch das Performance Tool Speed Tracer
und unterstützt das Deployment via Google App Engine. Der GWT-Ansatz muss aus zwei Blickwin-
keln betrachtet werden. Einerseits gibt es Komponenten, die serverseitig ausgeführt werden, ande-
rerseits wird die eigentliche Clientanwendung im Browser ausgeführt. Zunächst die Serverseite: Je
nach Anwendung soll der Client mit dem Server über HTTP-Aufrufe oder per GWT RPC kommu-
nizieren. Im Java-Umfeld tun wir das anhand einer Auswahl aus den unzähligen Frameworks, die
allesamt früher oder später auf die Servlet-Spezifikation aufsetzen. GWT RPC ist auch nicht anders
und basiert ebenfalls auf Servlets. Demnach benötigen wir für den serverseitigen Anteil einer GWT-
Anwendung einen Webcontainer.
Der clientseitige Teil einer GWT-Anwendung, also die Webanwendung an und für sich, entspricht ei-
gentlich einer JavaScript-Anwendung, die im Browser über DOM-Manipulation die HTML-Anwen-
dung entstehen lässt. Während der Entwicklung will man die aufwendige Java-zu-JavaScript-Trans-
formation vermeiden. Daher bietet das GWT-Team für verschiedene Browser bestimmte Browser-
Plug-ins für die Entwicklung an. Sie ermöglichen ein ferngesteuertes Manipulieren des DOMs im
Browser. Dadurch entfällt die Notwendigkeit der Transformation, die Manipulation kann ferngesteu-
ert aus der IDE heraus durchgeführt werden. Diese Vorgehensweise wird dann Developer-Modus
