Viele Default-Werte können bleiben

Als Nächstes kopiert man die erstellte XML-Datei in den Ordner xml_gui. Der vorerst letzte Schritt ist das Anpassen der web.xml. Dem Anwender präsentiert sich eine schier endlose Liste von init-Parametern des basicServlet. Wichtig ist vor allem, im guiApplDescFile-Parameter den Pfad zu der eigenen XML-Datei anzugeben. Den TCP/IP-Port für die Verbindung zum Swing-Thin-Client legt der swingPort-Parameter fest. An dem hier definierten Port startet nach dem Aufruf der Anwendung ein Listener. Der Programmierer muss also drauf achten, dass er nur freie Ports verwendet. Auf der sicheren Seite ist er, wenn er einen von der IANA als privat gekennzeichneten Port (zwischen 49152 und 65535) verwendet. Setzt man alle anderen init-Parameter auf die vorgeschlagenen Default-Werte, ist man schon fast am Ziel.

Im Anschluss wird das Beispiel in den Webcontainer der Wahl kopiert und als Webanwendung registriert. Möchte man den mit der Distribution ausgelieferten Jetty verwenden, bleibt nicht mehr viel zu tun. Lediglich in der webserver/WiSer-Server.xml ist ein Eintrag für die Anwendung zu ergänzen.

Ein erster Versuch über den Webbrowser (http://:/anwendungsname/start/) funktionierte einwandfrei. Das gleiche Ergebnis erreicht man mit dem Swing-Client und dem Swing-Fat-Client. Im Deployment Template fehlt noch ein HTTP-Skript für den Swing-Thin-Client. Letzterer unterscheidet sich von einem einfachen Swing-Thin-Client durch das Kommunikationsprotokoll (HTTP statt TCP/IP). Will man einen Swing-HTTP-Client verwenden, hilft das einfache Kopieren und Anpassen der Startdatei einer anderen Applikation aus dem bin-Ordner.

Das Ergebnis dieses ersten Versuchs ist einerseits beeindruckend und gleichzeitig ziemlich mager. Auf der Grundlage einer XML-Datei entstanden vier verschiedene Anwendungen mit einfacher Oberfläche – allerdings ohne Interaktion. Hier zahlt es sich aus, dass das WidgetServer-Framework dem MVC Pattern folgt. Als Nächstes spendiert man dem <button> eine Listener-Klasse. Dies geschieht durch das Hinzufügen des Elements

<srvListener
class="wisertest.helloheise.listener.HelloHeise_li">

Schließlich muss noch die Klasse programmiert werden. Im einfachsten Fall erstellt man sie direkt im Texteditor der Wahl und kompiliert sie mit javac. Deutlich mehr Komfort bietet eine integrierte Entwicklungsumgebung (IDE). Um den über das Eingabefeld entgegengenommenen Text zu verändern und im Label wieder anzuzeigen, muss das Programm nach dem Klick auf den Button ein UI-Event abfangen. Dies gelingt mit dem Java-Interface de.ug2t.unifiedGui.interfaces.IUnGuiEventListener. Es enthält nur eine Methode mit folgender Signatur:

public abstract void
pcmf_execListener(de.ug2t.unifiedGui.UnComponent
arg0) throws Exception 

Diese gilt es zu implementieren (Listing 1 ).

Aus einem Quellcode erzeugt der WidgetServer zwei verschiedene Darstellungen (Abb. 3). Das kleine Beispiel zeigt, wie vorbildlich die Objekte und Klassen im Framework benannt sind. Grauenvoll hingegen sind die notwendigen Casts der generischen Elemente auf UI-Elemente. Hier sollte man sich schon gut auskennen, um nicht zu viele Fehler zu produzieren. Die gleichen Probleme findet man allerdings auch bei anderen UI-Frameworks. Nach dem Kompilieren der Sourcen und dem anschließenden Deployment sieht man das Ergebnis, wie in Abbildung 3 dargestellt. Den Swing-Client kann man per Kommandozeile starten. Er besteht aus einer Framework-Klasse und bekommt eine XML-Konfiguration übergeben:

java -cp WiSerThinClient.jar; 
Piccolo.jar
de.ug2t.channel.runtime.swing.RtSwingClient
environment_helloheise_client.xml

In solchen environment_*.xml-Dateien werden die Konfigurationen der jeweiligen Swing-Clients hinterlegt.