root/documentation/doc.tex @ 79

\documentclass[11pt,a4paper]{article}

% packages
\usepackage{graphicx}
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage{listings}
\usepackage{color}
\usepackage{fancyhdr}

% style
\setlength{\textwidth}{150mm} 
\setlength{\textheight}{210mm} 
\pagestyle{fancy}
\addtolength{\headheight}{1ex} 
\renewcommand{\baselinestretch}{1.2}

% syntax colors
%\color{<colour>}
\definecolor{middlegray}{rgb}{0.5,0.5,0.5}
\definecolor{lightgray}{rgb}{0.8,0.8,0.8}
\definecolor{orange}{rgb}{0.8,0.3,0.3}
\definecolor{yac}{rgb}{0.6,0.6,0.1}

% meta
\title{AJAX + Google Web Toolkit}
\author{Torben Brodt}
\date{\today}
\fancyhead[L]{AJAX + Google Web Toolkit}
\fancyhead[R]{\thepage}
\fancyfoot[L]{Fachhochschule Wiesbaden, Medieninformatik}
\fancyfoot[R]{Torben Brodt}
\fancyfoot[C]{\ } % keine Seitenzahl unten

% content
\begin{document}
\maketitle % erzeugt den Titel mit Autor und Datum

% abstract
\begin{abstract}
Die Facharbeit handelt von der AJAX-Technologie - Grundlage moderner Web-Anwendungen. 
Sie beginnt bei der ErklÀrung der drei Basistechnologien DOM, JavaScript und HTTP, gibt ein Programmierbeispiel und geht auf typische Probleme ein.
Dann wird das Google Web Toolkit erklÀrt und eine BrÌcke zu Java geschlagen.
Das Google Web Toolkit versucht den Desktop-Entwicklungs-Zyklus auf Web-Anwendungen zu ÃŒbertragen.
Es werden Grundlegende Java-Kenntnisse und der sichere Umgang mit einer Entwicklungsumgebung vorausgesetzt.
\end{abstract}
\newpage
\tableofcontents
\newpage


\section{Einleitung} \label{sec:intro}
        Seit Web-Seiten existieren, gibt es auch den Begriff der Web-Anwendung.
        Der Begriff hat sich ÃŒber die Jahre stark gewandelt.
        Am Anfang war es die Bezeichnung fÃŒr einfache Formular-Interaktionen.
        Nach dem ersten AJAX-Medienrummel um das Jahr 2005,
        wurden aber neue Technologien bekannt, die eine Web-Anwendung Àhnlich mÀchtig machen konnten, wie man es von Desktop-Anwendungen kennt.

        Besonders im professionellen Umfeld wird wegen der einfachen clientseitigen Einrichtung und der strikten Server/Client Trennung verstÀrkt auf Web-Anwendungen gebaut.
        Moderne Web-Anwendungen lassen sich komponentenweise kombinieren, sie greifen ineinander ÃŒber und reagieren sofort Benutzeraktionen.
        
        Die BrÌcke zwischen Web- und Desktop-Welt wird durch gleiche Bedienkonzepte wie z.B. Drag\&Drop, AutovervollstÀndigung oder die sofortige Formularvalidierung geschlagen.

        In den folgenden Kapiteln wird erlÀutert, was die grundlegende Technologie 'AJAX' ausmacht und wie man sie als Programmierer fÌr sich nutzen kann.
        Weiter wird auf garantierte Stolpersteine eingegangen und letztendlich eine mögliche Antwort auf verschiedene Probleme prÀsentiert:
        Das Google Web Toolkit.


\section{EinfÃŒhrung in AJAX} \label{sec:ajax}
        AJAX steht fÃŒr Asynchronous JavaScript and XML.

        Vermutlich weiß jetzt niemand mehr als zuvor, doch es sollte immerhin klar geworden sein, 
        dass es ein Begriff aus der Informatik ist und man fÃŒr dessen Verwendung weder das gleichnamige Waschmittel, noch den Fußballverein kennen muss.

        AJAX ist keine Programmiersprache, sondern beschreibt das Konzept von drei Technologien: 
        DOM zur Manipulation von Web-Seiten, 
        JavaScript zur Ereignisbehandlung und 
        HTTP zum Nachladen von Daten.

        Das Zusammenspiel dieser drei Technologien erlaubt dynamische Websites, 
        die durch asynchrone Verbindungen in einer interaktiven Umgebung beliebige Datenmengen bewÀltigen können.
        
        Der Client schickt HTTP-Anfragen an den Server, ohne dass die eigentliche Seite neu geladen wird, oder der Benutzer wÀhrenddessen warten muss.
        
        \subsection{Document Object Model} \label{sec_ajax_dom}
        Das Document Object Model (kurz DOM) ist eine vom W3-Konsortium verabschiedete Norm fÃŒr die Definition einer Baumstruktur und ihrer Traversierungsfunktionen in XML.
        Mit DOM lÀsst sich also ein komplettes HTML Dokument in ein dynamisches Objekt binden.

        Das Beispiel zeigt den DOM-Baum einer Standard-Web-Seite, mit Head- und Body-Bereich und mehreren Unterknoten.
        \begin{figure}[htp]
        \centering
        \includegraphics{img/dom.eps}
        \caption{ReprÀsentierung einer Website in einem DOM-Baum}
        \label{fig:ajax_dom}
        \end{figure}
        
        In einer Client-Server-Architektur lÀsst sich DOM sowohl im Backend zur Dokumentengenerierung,
        als auch und im Frontend zum dynamischen Manipulieren nutzen.

        \subsection{JavaScript} \label{sec_ajax_javascript}
        Um Verwechslungen vorzubeugen, sei an dieser Stelle gesagt, dass es sich bei JavaScript weder um Java handelt, 
        noch dass konzeptionelle Ähnlichkeiten zwischen den beiden Sprachen existieren.
        JavaScript Code wird nicht fÃŒr die AusfÃŒhrung in einer VirtualMaschine kompiliert, sondern zur Interpretation im Klartext an den Browser ÃŒbertragen.
        Die AusfÌhrung des Codes lÀuft somit nicht auf dem Webserver, sondern auf dem eigenen Rechner ab.

        JavaScript lÀuft in einer Sandbox und schrÀnkt darÌber den Zugriff auf Netzwerkfunktionen oder das Dateisystem ein.

        Skripte werden in das HTML-Dokument eingebettet, um auf Ereignisse zu reagieren oder die DOM ReprÀsentierung der Website dynamisch zu manipulieren.

        Ein simples Beispiel ist der Aufruf der alert-Funktion.

\begin{lstlisting}[caption={JavaScript Hello World!}\label{lst:javascript_example},captionpos=b,language=html] 
<html>
<head><title>Test</title>
<script type="text/javascript">
alert("Hello World!");
</script>
</head><body>
</body></html>
\end{lstlisting}
        
        \begin{figure}[htp]
        \centering
        \includegraphics{img/alert.eps}
        \end{figure}

        FÃŒr die Programmierung mit JavaScript gibt es ein umfangreiches Online-Standardwerk unter http://de.selfhtml.org.
        

        \subsection{HTTP} \label{sec_ajax_http}
        HTTP ist ein zustandsloses Protokoll zur DatenÃŒbertragung zwischen zwei Computern.
        Ein Computer formuliert eine Anfrage.
        Der andere Computer beantwortet diese mit einem Inhalt.

        Normale Websites laden in einem Rutsch.
        Dazu formuliert der Client eine HTTP-Anfrage mit Hostnamen und Pfad.
        Wird die URL www.foo.com/ajax.html im Browser aufgerufen, wird die folgende Anfrage gesendet:
        
\begin{lstlisting}
GET /ajax.html HTTP/1.1
Host: www.foo.com
\end{lstlisting}
        
        Der Server beantwortet die Anfrage mit einem Status-Code und den angeforderten Daten:
\begin{lstlisting}[language=html]
HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <head>
    <title>Hello World!</title>
  </head>
<body>
  Hello World!
</body>
</html>
\end{lstlisting}
        
        Klickt man auf einen Link werden wieder und wieder neue HTTP-Anfragen geschickt und das komplette Dokument neu ÃŒbertragen.
        
        Das folgende Sequenzdiagramm beschreibt den Ablauf von Anfrage und Antwort.
        \begin{figure}[htp]
        \centering
        \includegraphics{img/http-classic.eps}
        \caption{Das klassische HTTP.}
        \label{fig:http-classic}
        \end{figure}
        
        \subsection{Asynchrones HTTP} \label{sec_ajax_asynchronous}
        AJAX erweitert dieses starre Konzept und erlaubt das asynchrone Senden und Empfangen von Daten ÃŒber HTTP.
        Das bedeutet, dass das Dokument nicht komplett geladen werden muss, 
        sondern es stattdessen wÀhrend der Laufzeit nachgeladen werden kann.
        WÀhrend des Ladevorgangs kann der Benutzer weiter mit der Seite interagieren,
        da der Browser dafÌr sorgt, dass die asynchrone Anfrage in einem eigenen Thread ablÀuft.

        Zudem ist keine Socketverbindung auf Ebene von TCP oder UDP notwendig.  
        Das EinfÃŒgen in den DOM Baum erledigt dann JavaScript.

        So funktioniert das Zusammenspiel der drei Technologien:
        Die Ajax-Engine reagiert auf einen Klick in der BenutzeroberflÀche,
        schickt daraufhin eine HTTP-Anfrage an den Server und sobald dieser antwortet,
        wertet sie die Antwort aus und fÃŒgt die Informationen mit DOM-Manipulationen in das eigentlich Dokument wieder ein.

        \begin{figure}[htp]
        \centering
        \includegraphics{img/http-ajax.eps}
        \caption{Eine AJAX Anfrage ÃŒber HTTP.}
        \label{fig:http-ajax}
        \end{figure}


\section{AJAX Programmierung} \label{sec:ajax_programming}
        FÃŒr fertige AJAX Kunstwerke gibt es viele unterschiedliche JavaScript basierte Frameworks.
        FÌr das VerstÀndnis genÌgt es aber sich den AJAX-Kern anzuschauen.
        Dieser besteht aus dem XMLHttpRequest im Browser und der Skriptsprache JavaScript, ÃŒber das dieser angesprochen wird.
        
        \subsection{Ereignisbehandlung mit EventHandlern} \label{sec_ajax_eventhandler}
        Die HTTP-Anfragen werden durch JavaScript Ereignisse ausgelöst.
        EventHandler sind das Bindeglied zwischen HTML und JavaScript.
        Das W3-Konsortium hat sie als HTML-Attribut in den Sprachstandard aufgenommen.

        Hier ist ein Handler definiert, der ausgelöst durch einen Mausklick die Funktion foo() aufruft.
        An dieser Stelle wird davon ausgegangen, dass die Funktion foo() existiert.
        Sie wird im Beispiel nachgereicht.
\begin{lstlisting}[language=html] 
<div onclick="foo()">Container</div>
\end{lstlisting}

        Es sind alle erdenklichen Ereignisse möglich.
        JavaScript kann genauso auf das Fokussieren oder Verlassen von Eingabefeldern reagieren, 
        wie auf das Überfahren eines Elements mit der Maus.    
        
        \subsection{XMLHTTP als Kommunikationsschnittstelle} \label{sec_ajax_xmlhttprequest}
        Das XMLHttpRequest Objekt ist eine API, die den HTTP-Zugriff auf Websites der eigenen Domain\footnote{W3C-Vorschlag fÃŒr eine Cross-Site-Extension in 'XMLHttpRequest 2' unter http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012.html} erlaubt.
        FÌr die Kommunikation Ìber das HTTP-Protokoll werden die beiden gebrÀuchlichsten Anfrage-Methoden POST und GET genutzt.
        Wurde ein Event ausgelöst und eine Anfrage abgeschickt, Ìbernimmt das XMLHttpRequest den Aufruf der Callback-Methode.

        Aus historischen GrÌnden wird das XMLHttpRequest Objektes von den meisten Browser unterschiedlich initialisiert und sollte daher stets gekapselt werden.\footnote{Eine Implementierung fÌr die gÀngigsten Browser findet man unter http://de.wikipedia.org/wiki/XMLHttpRequest}
        
        \subsection{Callback Methoden} \label{sec_ajax_callback}
        Die Callback Methode ist die 'RÃŒckruf'-Funktion mit einer Antwort vom Server.
        Das XMLHTTP Objekt initialisiert die Callback Methode und ruft sie nach jeder readyState-Änderungen auf.
        Erst beim Status Vier steht das gesamte Dokument zur VerfÃŒgung.

        Wann und ob die readyStates tatsÀchlich wechseln, kann auf Grund vieler Einflussfaktoren wie Bandbreite und Serverauslastung nie garantieren werden.
        Die Callback Methode ist daher als eine void-Funktion ohne RÃŒckgabewert zu implementieren.
        HÀufig nutzt man den Callback, als eine anonyme Methode.
        
        \subsection{VollstÀndiges Beispiel} \label{sec_ajax_example}
        Nun ist alles bekannt, was benötigt wird, um die Funktion foo() zu implementieren.
        Sie soll eine AJAX Anfrage ausfÃŒhren, um eine Liste von Namen nachzuladen.
        Dazu wird die AJAX Klasse initialisiert und eine GET-Anfrage an backend.php geschickt.
        Diese liefert im Beispiel folgendes XML Dokument.
\begin{lstlisting}[language=xml] 
<root>
  <online>hans</online>
  <online>peter</online>
  <online>gunther</online>
</root>
\end{lstlisting}
        
        In unserer anonymen Callback Methode, können wir die Daten mit DOM traversieren und in den Node mit appendChild direkt in den Website-Context einfÌgen.
\begin{lstlisting}[caption={VollstÀndiges AJAX Beispiel}\label{lst:ajax_example},captionpos=b,language=java] 
function foo() {
  var req = new XMLHttpRequest(); //mozilla implementierung
  req.open('get', 'backend.php');
  req.onreadystatechange = function() {
    if ((req.readyState == 4) && (req.status == 200)) { 
      var domZiel = document.getElementById('context');
      var xmlQuelle = req.responseXML.getElementsByTagName('online');
      for(var i=0; i<xmlQuelle.length; i++) {
        domZiel.appendChild(xmlQuelle[i]);
      }
    }
  }
  req.send(null);
}
\end{lstlisting}


        \subsection{Probleme in AJAX} \label{sec_ajax_prob}
        Das Arbeiten mit den am meisten verbreitetsten Web-Technologien HTML und JavaScript stellt die Entwickler vor eine neue Herausforderung.
        
        Bei der normalen GUI-Programmierung kann die Anwendung bereits innerhalb der Entwicklungsumgebung debuggt und getestet werden.
        Da JavaScript-Anwendungen aber erst beim Endbenutzer interpretiert werden,
        benötigt der Entwickler verschiedene Testsysteme aus Betriebssystem- und Browserkombinationen.
        Auch der komplette Klick-Lebenszyklus wird durch das besondere Verhalten der Callback-Methoden und die strikte Trennung zwischen der JavaScript-Frontend-Implementierung und der Backend-Implementierung schier unmöglich zu testen.
        Es werden Testszenarien gebraucht die eine ServerÃŒberlastung emulieren.
        
        Selbst fÃŒr den Benutzer ergeben sich Nachteile. 
        Denn das Navigieren Ìber die Browserfunktionen oder das Neuladen der Seite können ohne ein ausgeklÌgeltes Konzept zu Fehlverhalten fÌhren.

        Wie der Titel dieser Ausarbeitung nahe legt, heißt die Lösung fÃŒr all diese Probleme 'Google Web Toolkit' (oder kurz GWT).

        Das GWT erlaubt eine Entwicklung fern von HTML und JavaScript und verwendet dazu hundertprozentig reines Java.
        Dieses Kernkonzept wird in den folgenden Kapiteln erlÀutert.


\section{Google Web Toolkit} \label{sec:gwt}
        \subsection{EinfÃŒhrung in das Google Web Toolkit} \label{sec_gwt_intro}
        Das Google Web Toolkit ist ein Java Framework zum Entwickeln von Web-Anwendungen, fÌr die keine Java Umgebung benötigt wird.
        So widersprÃŒchlich das Konzept klingen mag, um so mehr ÃŒberzeugt es durch die vielen Vorteile.

        Das komplette Frontend wird zwar in Java entwickelt,
        der GWT-Compiler konvertiert die Java Klassen aber dann zu browserinterpretierten JavaScript- und HTML Codes, 
        wie sie auf jedem Webspace und ohne marginale Systemvoraussetzungen verwendet werden können.

        Entwickler können ihre fÌr Java bevorzugte Entwicklungsumgebung benutzen.
        Dabei brauchen sie sich nicht mit HTML, JavaScript und vor allem den ganzen Browser-Workarounds auseinander zu setzen.
        Sie können GUIs programmieren, wie sie es bereits von SWING und AWT gewohnt sind, 
        ohne dabei auf vorhandene Build- und Testing-Tools verzichten zu mÃŒssen.


        \subsection{Entwicklungszyklus} \label{sec_devcycle}
        Das GWT arbeitet mit einer Standard-Verzeichnisstruktur, die entweder manuell oder unterstÃŒtzt durch die mitgelieferten Skripte erstellt werden kann.
        FÃŒr Eclipse wird erst ein Projektverzeichnis zum Import in den Workspace erstellt und dann im zweiten Schritt die Anwendung angelegt.

        Die Schritte sollten in einem leeren, eigenen Verzeichnis durchgefÃŒhrt werden, da die Verzeichnisstruktur direkt im ausfÃŒhrenden Verzeichnis abgelegt wird.
\begin{lstlisting}[language=bash]
projectCreator -eclipse MeineErstesProjekt
applicationCreator -eclipse MeineErstesProjekt \
        com.gwt.client.MeineErsteAnwendung
\end{lstlisting}

        Geeignete Entwicklungsumgebungen können das Projektverzeichnis dann als normales Java-Projekt importieren und die eigentiche Programmierung kann beginnen.
        Die Entwicklungsumgebung kann dabei mit Debugging-Möglichkeit, Refactoring-Tools und einer Unit-Testing-Integration unterstÌtzen.
        Die Standard-Verzeichnisstruktur enthÀlt bereits ein einfaches 'Hello World', das im nÀchsten Kapitel zu einer Anwendung wachsen wird.
        
        WÀhrend des Testens wird öfter in den Hosted-Mode gewechselt, der einen Browser innerhalb einer Java VirtualMachine emuliert.
        Die Anwendung kann hier live getestet und - entsprechende Break-Points vorausgesetzt - auch debuggt werden.
        
        Skriptsprachen-Programmierer mÃŒssen ihr 'Try and Run' Konzept nicht verwerfen, 
        da der Hosted-Mode-Browser sie weder durch umstÀndliche Entwicklungsumgebungs-Prozesse, 
        noch durch lange Kompilierzeiten ausbremst.
        Änderungen im Java Quelltext Code werden 'Just in time' ÃŒbernommen.
        
        Wurde entschieden den fertig konfigurierten Tomcat-Server des Toolkits zur Prototype-Backend-Implementierung zu verwenden,
        kann der komplette Anwendungszyklus debuggt werden. 
        Dadurch kann ein GUI Klick von vorne, bis hinten debuggt werden, wie es sonst mit AJAX nicht möglich gewesen wÀre.

        Wenn die Anwendung fertig erstellt ist und sie mit dem Code im Hosted-Mode zufrieden sind, 
        kann die Anwendung mit dem GWT-Compiler in JavaScript- und HTML-Code umgewandelt werden.
        
        Am Ende mÃŒssen die Dateien nur noch auf dem Webserver deployed werden. 


\section{Technik des GWT} \label{sec:tec}
        \subsection{Compiler} \label{sec_tec_compiler}
        Der Compiler ist das HerzstÃŒck des GWT. Er verarbeitet den programmierten Java-Code und erstellt daraus einen neuen Code aus HTML und JavaScript - 
        so wie ein klassischer Java Compiler aus Java-Code einen Bytecode erstellt.
        Der Unterschied ist, dass der erstellte Code ohne Java Runtime Umgebung und mit jedem aktuellen Browser ausgefÃŒhrt werden kann.

        Beim Compilieren wird entschieden welche Funktionen des GWT ÃŒberhaupt genutzt werden.
        FÌr eine simple 'Hello World' werden also keine hundert Kilobytes an Bibliotheken mitgeliefert, sondern nur die Funktionen die tatsÀchlich benötigt werden.

        Außerdem wird der Quelltext komprimiert und komplett in JavaScript Dateien ausgelagert.
        Dadurch kann die gesamte Anwendung vom Browser zwischengespeichert werden.

        FÃŒr jede Kombination aus Gebietsschema und Browsertyp wird eine einzelne JavaScript Datei erstellt.
        Das erzeugt zwar mehr Daten auf dem Server (meist in einer Größenordnung von Kilobytes), 
        aber durch ein automatisches Bootstrap-Skript wird fÃŒr den Benutzer nur die Datei geladen, 
        die er tatsÀchlich benötigt.
        
        Wurde vor einen Framework-Einsatz vorher noch zwischen sauberem Code und Mengen an unbenutztem Framework-Code abgewÀgt,
        kann mit dem GWT fast nur gespart werden.
        
        Die eigentliche HTML Datei sorgt nur fÃŒr die Einbindung des JavaScripts.


        \subsection{ImageBundles} \label{sec_tec_gwt_imagebundles}
        Ein weiterer Grundprozess des GWT ist es die Anzahl an HTTP-Anfragen so gering wie möglich zu halten.
        Auch hierfÃŒr sorgt der Compiler.
        In den meisten Websites sind es Bilder, die die meisten HTTP-Anfragen verursachen.
        Daher haben sich die GWT Entwickler das Konzept der ImageBundles ÃŒberlegt.
        Vielleicht wird der Vorteil anhand eines Beispiels bewusster:

        Typische WYSIWYG-Editoren bringen etwa 50 Buttons mit, die dem Anwender eine Office-Àhnliche OberflÀche vermitteln sollen.
        Ein Browser wÃŒrde an dieser Stelle 50 Bilder-Tags im HTML-Quelltext sehen und alle 50 Bilder per HTTP-Anfrage laden.
        Selbst wenn der Besucher die Seite bereits besucht hat und alle Bilder nur aus dem Zwischenspeicher des Browsers geladen werden mÃŒssen, 
        mÌssen 50 Verbindungen aufgebaut werden um nachzufragen, ob sich eines der Bilder geÀndert hat.
        Das GWT macht nun aus den 50 Bildern nur ein einziges Bild, das die selbe Datenmenge mitbringt, nur einmalig geladen werden muss und trotzdem zwischengespeichert wird.
        Eingebunden werden die Bilder weiterhin ÃŒber die 50 Bilder-Tags in ihrer Originalgröße.
        Per CSS werden Sie aber so verschoben, dass der Endanwender, bis auf den Geschwindigkeitsvorteil keinen Unterschied mehr merkt.
        \begin{figure}[htp]
        \centering
        \includegraphics{img/imagesample.eps}
        \caption{Hinter einem Bild verstecken sich in Wirklichkeit weitere.}
        \label{fig:imagesample}
        \end{figure}
        
        ImageBundles werden als Interface geschrieben.
        Sollen die Bilder zentral verwaltet werden, werden sie per Ableiten zusammengefasst und der Compiler erstellt ein einziges Bild.
        
        
        \subsection{Remote Procedure Call} \label{sec_tec_gwt_rpc}
        Bisher wurden die optimierten Frontend-Prozesse des GWT vorgestellt.
        FÃŒr die Anbindung an ein Backend nutzt das GWT 'Remote Procedure Calls' (kurz RPC), 
        ÃŒber die eine Model-View-Controller Architektur umgesetzt werden kann.

        FÃŒr die Prototyp-Entwicklung des Backends bringt das Google Web Toolkit einen Tomcat Server mit.
        Das Toolkit fasst also alles benötige in einem Paket zusammen.
        Falls kein Applikation-Server zur VerfÃŒgung steht,
        stellt dies durch die Standardisierung von Remote Procedure Calls auch kein Problem dar und 
        es können andere Programmiersprachen wie PHP, Python oder C\# im Backend genutzt werden.

        Eine Besonderheit der RPC Implementierung des GWT, 
        die das Debuggen erleichtern, 
        sind die polymorphen Klassenhierarchien und das Durchreichen von Exceptions.
        
        Die Implementierung von RemoteProcedure Calls erstreckt sich ÃŒber mehrere Klassen und Interfaces.
        Aufbauend auf dem 'Hello World' wird nun die Beispielanwendung der AJAX-Programmierung implementiert.
        
        Nach Konvention sollten dazu neben dem existierenden Client-Paket noch 'rpc' und 'server' Pakete angelegt werden.
        Das rpc-Paket wird die folgende Klassenstruktur abbilden, die zustÀndig fÌr die Remote Procedure Calls sind.
        Komplexe Datentypen sind erlaubt.
        Daher wird das rpc-Paket auch die Klassen enthalten, die ÃŒber HTTP ausgetauscht werden.
        
        \begin{figure}[htp]
        \centering
        \includegraphics{img/uml.eps}
        \caption{UML Modell der Beispielanwendung 'Status'}
        \label{fig:rpc}
        \end{figure}
        
        Status ist ein Interface das RemoteService erweitert und die tatsÀchliche Implementierung beschreibt.
        Es enthÀlt die Java-Signaturen und wird spÀter vom Backend implementiert.
\begin{lstlisting}[language=java] 
import com.google.gwt.user.client.rpc.*;

public interface Status extends RemoteService {
  Person[] getActive();
  void setStatus(Person name, boolean status);
}
\end{lstlisting}
        
        StatusAsync ist ein Interface das spÀter im GWT-Frontend-Code instanziiert wird.
        Die Methoden haben keinen RÃŒckgabetyp, erhalten jedoch das parametrisierte AsyncCallback Objekt, das auf die readyState Änderungen reagiert.
\begin{lstlisting}[language=java] 
import com.google.gwt.user.client.rpc.*;

public interface StatusAsync {
  void getActive(AsyncCallback callback);
  void setStatus(Person name, boolean status, AsyncCallback callback);
}
\end{lstlisting}
        
        Der Status-Proxy beschreibt die Instantiierung im Frontend.
        Er ist eine StatusAsync Instanz, wird aber vom GWT initialisiert.
        Hier wird er die URL des RPC Moduls des GWT genutzt.
        Alternativ kann man aber auch einen Pfad zur eigenen RPC Implementierung eintragen.
\begin{lstlisting}[language=java] 
StatusAsync status = 
  (StatusAsync) GWT.create(Status.class);
ServiceDefTarget endpoint = (ServiceDefTarget) status;
String moduleRelativeURL = GWT.getModuleBaseURL() + "rpc";
endpoint.setServiceEntryPoint(moduleRelativeURL);

AsyncCallback callback = new AsyncCallback() {
  public void onSuccess(Object result) {
    Person[] list = (Person[]) result;
    for(int i=0; i<list.length; i++) {
      Window.alert(list[i].getName());
    }
  }

  public void onFailure(Throwable caught) {
    Window.alert(caught.getMessage());
  }
};
\end{lstlisting}
        
        Wird die Anwendung mit dem mitgelieferten Tomcat-Server getestet, 
        muss das Backend das Status-Interface implementieren und der Pfad zum Servlet in der gwt-Modulkonfiguration eingefÃŒgt werden.
        In der public/MeineErsteAnwendung.gwt.xml wird dazu ein neuer XML-Knoten unter '<module>' eingefÃŒgt.
\begin{lstlisting}[language=xml] 
        <servlet path="/rpc" class="com.gwt.server.StatusImpl"/>
\end{lstlisting}



\section{Elemente des GWT} \label{sec:elements}
        Neben den behandelten Performance-Vorteilen, durch die erst eine Reaktionszeit Àhnlich der von Desktop- möglich wurde,
        bringt das GWT Basiselemente fÌr die GUI-Programmierung und Konzepte um die Usability von Web-Anwendungen zu erhöhen mit.

        \subsection{Panels} \label{sec:gwt_panels}
        Wer grafische OberflÀchen bereits mit Java erstellt hat, kennt das Layout-Manager-Konzept von Swing und AWT.
        Abgesehen von ein paar Besonderheiten von HTML-Elementen wird das Konzept beliebig kombinierbarer Panels auch im GWT angewandt.

        Panels sind Container um andere Elemente aufzunehmen.
        Es gibt verschiedene Panels fÃŒr Layout und Content.
        Ein typisches Beispiel fÃŒr ein Layout-Panel ist das DockPanel.
        Es kann als Grundlayout verwendet werden und Àhnelt dem BorderLayout von AWT.

        \begin{figure}[htp]
        \centering
        \includegraphics{img/panel.eps}
        \end{figure}

        \subsection{Widgets} \label{sec:gwt_widgets}
        Hinter Widgets versteckt sich der deutsche Begriff 'grafisches Bedienelement'.
        Das GWT versteht sich auf Webanwendungen, und so wird es auch die gewohnten Browser-Elemente aus Usability-Aspekten behalten.
        Neben den fÃŒr HTML Entwickler bekannten Elementen wie Eingabefeld, Button und Auswahlbox bringt das GWT aber noch weitere, aus Desktop-Applikationen bekannte Widgets mit. 
        Dazu zÀhlen der Tree fÌr eine Baumdarstellung eines Verzeichnisbaums, 
        die MenuBar fÃŒr eine MenÃŒleiste, 
        die TabBar fÃŒr das Container-Wechsel ÃŒber eine Reiterleiste,
        das StackPanel oder die RichTextArea fÃŒr WYSIWYG-Editoren.

        Außerdem gibt es neben Kalender- und Zeichenwidgets auch 'Drag \& Drop' Elemente aus der aktiven OpenSource Community hinter dem GWT.


        \subsection{Implementierung der Browser-History} \label{sec:usability_history}
        Ein typischer Kritikpunkt und Stolperstein bei Web-Anwendungen ist die Browserhistorie, 
        die entweder nicht funktioniert oder von der kontextuell abgeraten wird.

        Das asynchrone Konzept von AJAX macht ein Neuladen der Website unnötig, wodurch es fÌr den Browser keinen Anlass gibt einen History-Eintrag zu erstellen.
        Dadurch, dass sich fÌr den Benutzer aber Inhalte Àndern, nimmt er an, dass er den 'ZurÌck'-Button nutzen kann.

        Es gibt verschiedene Workarounds fÃŒr dieses Problem, die sich zu Quasi-Entwurfsmustern entwickelt haben, aber nicht einfach zu implementieren sind.

        Das GWT hat diese Implementierung bereits vorgenommen und kann vom Programmierer abstrakt genutzt werden.
        Hier zeigt sich wieder der Vorteil eines Frameworks:
        Gibt es in der Zukunft eine bessere Technik braucht der Entwickler nur die Google JAR auszutauschen.
        
        Die Implementierung funktioniert mit der Schnittstelle HistoryListener, die onHistoryChanged(String token) implementiert.
        Das Token lÀsst sich wie ein Dateiname behandeln.
        Dadurch kann jede GUI-Aktion durch ein Token abgebildet werden.


        \subsection{Internationalisierung} \label{sec:tec_internationalization}
        Das GWT unterstÌtzt den Entwickler mit verschiedenen Möglichkeiten um sowohl die Sprache, 
        als auch unterschiedliche Zahlen- oder Datumsformaten zu internationalisieren.

        Die bevorzugte Art der Implementierung ist die statische bei der die Sprachvariablen schon zur Compilierzeit befÃŒllt werden.
        WÀhlt man stattdessen die dynamische Internationalisierung werden dem Benutzer alle Dateien mitgeliefert.
        
        Bei der statischen Variante wird ein Interface mit je einer Methode pro Eigenschaft erstellt.
\begin{lstlisting}[language=java]
public interface MyLang extends Constants {
        String helloWorld();
        String sliceOfSpam();
}
\end{lstlisting}

        Eine Instanz dieser Schnittstelle greift dann auf eine Property-Datei namens MyLang.properties zu.
        Wurde eine weitere Sprache (z.B. 'en') ÃŒber die globale Konfigurationsdatei gwt.xml bekannt gemacht,
        wird auch fÃŒr die Sprache 'en' und die Datei MyLang\_en.properties ein JavaScript kompiliert.
        
        Die Sprache wird je nach Browserkonfiguration automatisch gewÀhlt. 
        Mit dem GET-Parameter 'locale' lÀsst sie sich aber auch erzwingen.


        \subsection{Eigene Skripte} \label{sec:scripting}
        Es ist gÀngige Praxis neue Widgets zu bauen indem vorhandene Widgets und Panels des GWT kombiniert werden.
        Das erleichtert die Pflege bei Versionsupdates und verhindert, dass der Programmierer wieder auf JavaScript Ebene herunter muss um Änderungen einzupflegen.

        Falls aber doch individuelle Effekte, fertige Bildergallerien oder Ähnliches benötigt werden,
        bietet das GWT Ìber JSNI die Möglichkeit normalen JavaScript Code einzubinden.

        Soll eine solche Methode geschrieben werden, wird das SchlÃŒsselwort 'native' und eine spezielle Kommentarsyntax verwendet.
        Wie im folgenden Beispiel zu sehen, ist selbst ein Zugriff auf Attribute und Methoden des GWT möglich.

        Der Zugriff auf 'window' und 'document' ist gekapselt und nur Ìber die Variablen \$wnd und \$doc möglich.

\begin{lstlisting}[language=java] 
public class JSNIExample {
  void foo(String s) {
    private FlowPanel fp = new FlowPanel();
    private Button b1 = new Button(s+" 1");
    private Button b2 = new Button(s+" 2");
  }

  public native void foo(JSNIExample x, String s) /*-{
    $wnd.alert(msg);
    this.@book.JSNIExample::foo(Ljava/lang/String;)(s);
  }-*/;
}
\end{lstlisting}


\newpage

\begin{thebibliography}{99}
\bibitem{gwtinaction}
Robert Hanson \& Adam Tacy: 
{\em GWT im Einsatz}.
Hanser Verlag,
2007, ISBN 3446412417
\bibitem{entwicklerpress} Ralph Steyer:
{\em Das Google Web Toolkit. schnell + kompakt}.
Entwickler.Press,
2007, ISBN 3939084379
\bibitem{dewsbury} Ryan Dewsbury:
{\em Das Google Web Toolkit. schnell + kompakt}. 
Addison-Wesley Longman, Amsterdam
2007, 0321501969
\bibitem{official} Google:
{\em Offizielle Dokumentation}. 
http://code.google.com/webtoolkit/
\end{thebibliography}

\newpage

\end{document}