Ein rudimentäres Raum-Reservierungssystem mit Webmacro (offensichtlich auch für Hilbert-Räume).

Application Server als Basis von Web-Anwendungen stellen nur die Ablaufumgebung für Servlets und JSPs zur Verfügung. Toolkits für die eigentliche Erstellung von Webseiten sind meist nicht Teil des Servers. Wir schauen uns OpenSource-Lösungen an, die diese Lücke schließen.

Es ist ein weit verbreiteter Irrtum, dass eine Web-Anwendung eine Client-Server-Anwendung ist, die halt nur eine andere Benutzerschnittstelle hat. Die klassische Client-Server-Anwendung und eine Web-Anwendung haben zwar vieles gemeinsam, aber die Unterschiede sorgen dafür, dass ein unbedarftes Herangehen an Web-Anwendungen schnell bestraft wird. Ein Teil der Unterschiede ist technischer Natur, der andere betrifft den Kontext, für den Web-Anwendungen erstellt werden. Ich beleuchte zuerst den technischen Aspekt, danach geht es um die Begleitumstände.

Technische Unterschiede

Ein Hauptunterschied zu normalen Client-Server-Anwendungen ist die Tatsache, dass die Verbindung zwischen Browser und Server zustandslos (stateless) ist. Da aber nur in sehr einfachen Fällen darauf verzichtet werden kann, den aktuellen Status des Clients (etwa die gewählten Produkte eines Web-Shops) von Request zu Request zu sichern, ist hier einiges an Aufwand dafür nötig, aus einer technischen Verbindung ohne Status eine logische Verbindung mit Status zu machen. Hier kommen die ungeliebten Cookies oder Techniken wie URL-Rewriting ins Spiel, mit denen Session-IDs über versteckte Parameter übertragen werden.

Ein weiteres einflussreiches Problem betrifft das Rendering. Wie bei einer normalen Client-Server-Anwendung übernimmt der Client, also der Browser, die Darstellung des GUI. Bei einer normalen Anwendung hat aber das Programmierteam sowohl den Serverteil als auch den Client programmiert und aufeinander abgestimmt. Die Fähigkeiten des Browsers entziehen sich aber zum Teil der Kontrolle des Servers, obwohl am Server über die dynamisch erstellten Webseiten das Aussehen der Benutzerschnittstelle entschieden wird.

Aufwändige Web-Anwendungen verlagern deshalb einen Teil des Renderings wieder auf die Serverseite, indem der Browsertyp abgefragt und die Seiten entsprechend aufbereitet werden. Ein Teil des Zeitgewinns bei der Entwicklung, den der Web-Ansatz verspricht, geht dadurch wieder verloren. Außerdem funktioniert die serverseitige Aufbereitung nur bis zu den nächsten neuen Versionen der verwendeten Browser.

Fast nebensächlich erscheint dagegen das Problem der eingeschränkten Möglichkeiten, die HTML bietet. Moderne GUI-Toolkits mit ihren vielfältigen Widgets und den damit an die Problemkreise angepassten Benutzerschnittstellen sind mit HTML nicht zu erreichen. Aber eine einfache Benutzerschnittstelle muss ja nicht schlecht sein, da weniger oft mehr ist.

Wer jedoch aus der klassischen GUI-Programmierung kommt, tut sich mit HTML recht schwer. Statt GUI-Objekte zu erzeugen und zu manipulieren, muss HTML-Text ausgegeben werden. Weiter unten stelle ich zwar verschiedene Toolkits vor, die den HTML-Text innerhalb von Objekten kapseln, ein Problem bleibt aber immer bestehen: Es gibt (noch) eine gemeinsame Sprache der Programmierer. Oder anders ausgedrückt: Wer einmal beispielsweise eine KDE- oder Swing-Anwendung geschrieben hat, kann ohne übergroßen Aufwand die Seite wechseln, denn Buttons, Labels, Entry Fields gibt’s hier wie dort. Bei Web-Anwendungen sieht es dagegen anders aus. Jede Site verwendet einen anderen Ansatz, die sich oft grundlegend in Philosophie und Methoden unterscheiden.

Optisches Design als Komplexitätsfaktor

Nahtlos an das gerade Gesagte schließen sich einige Probleme an, die zwar eher im menschlichen Bereich liegen, aber gelegentlich für umso größere Kopfschmerzen sorgen. Jede Anwendung sollte zwar auf Benutzbarkeit geprüft werden und größere Firmen haben dafür extra Abteilungen, aber das grundlegende Aussehen der Anwendung ist durch das GUI-Toolkit vorgegeben.

Der Vorteil liegt auf der Hand. Wer grafische Anwendungen aus der frühen X11-Zeit mit heutigen KDE- oder Gnome-Anwendungen vergleicht, merkt schnell den Unterschied. Damals musste jede Anwendung anders bedient werden, jede neue Anwendung war ein neues Abenteuer. Heute finde ich ähnliche Grundfunktionalitäten immer an derselben Stelle im Menü über dieselben Shortcuts.

Das Web dagegen ist eher mit der Frühzeit der grafischen Benutzerschnittstellen vergleichbar. Designer bestimmen das Aussehen und die Benutzerführung – und damit prallen zwei Welten aufeinander, denn das FFF-Prinzip (Form follows Function) des typischen Programmierers wird von Designern oft nicht geteilt. Unabhängig davon sorgt aber allein die Tatsache, dass neben den Programmieren noch weitere Interessengruppen an einem Programm mitwirken, zu Verzögerungen. Irgendwann ist bekanntlich immer der Punkt gekommen, an dem mehr Mitarbeiter ein Projekt verzögern, statt zu beschleunigen.

Ein Argument für die Designer-Seite ist der Einsatzzweck von Web-Anwendungen. Solange sie für den Verkauf von Produkten eingesetzt werden, ist eine Investition auf dieser Seite sinnvoll. Aber mehr und mehr normale Anwendungen finden ihren Weg auf die (Intranet-)Applikationsserver, und hier ist die schnelle Erstellung und einfache Benutzbarkeit wichtiger als ein schönes Aussehen.

Abbildung 1: So sieht das MVC-Modell aus.

MVC im Web

Nach diesen Hintergrundbetrachtungen wird es jetzt aber wieder technisch. Es folgt ein Einstieg in die Programmierung von Web-Anwendungen nach dem MVC-Design. MVC steht für Model-View-Controller und beschreibt ein Design (im Gegensatz zu oben ist hier das technische Design einer Anwendung gemeint), das sich für GUI-Anwendungen als Quasi-Standard etabliert hat. Die einzelnen Komponenten haben dabei folgende Aufgaben:

• Das Model enthält die eigentliche Funktionalität der Anwendung. Dazu gehören die Daten sowie der Status der Anwendung. Ein typisches Beispiel ist das Ergebnis einer Query. Das Model kennt weder eine View noch den Controller.
• Die View ist für das Aussehen der Anwendung zuständig. Sie kann lesend auf das Model zugreifen, aber nicht schreibend. Die View kennt also das Model, aber nicht den Controller.
• Der Controller schließlich reagiert auf die Benutzereingaben, erzeugt und verändert das Model und wählt gegebenenfalls eine View aus. In normalen Swing-Anwendungen bilden die Event-Listener den Controller.

Bei klassischen Anwendungen wird die View vom Model durch einen Event-Mechanismus über Änderungen der Daten informiert, damit sie sich neu anzeigt. Für die allererste Anzeige lässt sich dieser Mechanismus auch im Web implementieren. Die View ist ja letztlich nichts anderes als eine dynamisch erzeugte Seite, kapselbar in einem Objekt, das benachrichtigt werden kann.

Bei später erforderlichen Änderungen ist wegen des Request-Response-Verfahrens von HTTP ein automatisches Update der View allerdings nicht möglich. Bei Web-Anwendungen erfolgt ein Refresh daher erst nach dem nächsten Request (falls der die betreffende Seite nochmals angezeigt haben möchte).

Mancher Leser wird jetzt zurecht fragen: Warum der ganze Aufwand? Mit etwas Perl, PHP oder ähnlichen Skriptsprachen ist es doch ganz einfach, dynamische Webseiten zu erzeugen. Das ist richtig, jedoch nur dann, wenn man sich im linken Teil des Aufwands-Komplexitäts-Diagramms befindet (siehe Abbildung 2). Kleine dynamische Seiten sind zwar schnell implementiert, aber ich habe auch schon gesehen, dass ähnliche Seiten durch fortgesetztes Cut & Paste erzeugt werden, mit dem Effekt, dass bei jeder kleinen Änderungen viele Seiten anzufassen sind. Und wer schon mal Webseiten mit 1000 Zeilen Skript gesehen hat, fängt doch irgendwann mal damit an, ein ordentliches Design zu schätzen.

Alle im Folgenden vorgestellten Softwarepakete versuchen den Prozess der Webseiten-Erstellung zu vereinfachen, indem sie Lösungen für die am Anfang angesprochenen Problemkreise anbieten. In den meisten Fällen steht dabei das MVC-Design-Paradigma im Mittelpunkt. Die Ansätze sind jedoch sehr unterschiedlich, so dass für jeden Geschmack etwas dabei sein sollte.

Abb. 2: Aufwand und Komplexität bei Webseiten.

Webmacro

Webmacro – verfügbar über [1] – stellt eine Template-basierte Lösung für die Webseiten-Erstellung bereit. Der Webdesigner baut dabei seine Seiten über eine bewusst einfach gehaltene Macro-Sprache auf, in der er Platzhalter für dynamischen Text einfügt. Ein einfaches Beispiel ist in Listing 1 zu sehen. In dieser Seite gibt es nur einen dynamischen Text, der durch den Platzhalter $message bestimmt wird.

Das zu so einem Webmacro-Template gehörige Model ist einfach eine Subklasse der normalen Hashtable-Klasse. Der Controller, in der Regel eine von org.webmacro.servlet.WMServlet abgeleitete Klasse, füllt dabei den Hashtable mit den Werten, etwa:

context.put("message","Bitte Werte eingeben!");

Die Webmacro-Engine durchsucht bei der Erzeugung der Webseite den Hashtable nach geeigneten Objekten. Ein Platzhalter könnte zum Beispiel auch die Form $person.vorname haben, dann wird nach einem Objekt mit Namen person im Hashtable gesucht, das entweder ein öffentliches Attribut vorname enthält oder eine Methode getVorname().

Webmacro hatte ich mir schon vor mehr als einem Jahr zum ersten Mal angesehen. Damals dachte ich, dass die Welt nun wirklich keine weitere skriptbasierte Web-Macrosprache braucht. Einer genaueren Betrachtung hält dieses Vorurteil aber nicht stand. Die Webmacro-Sprache ist so eingeschränkt, dass damit keinerlei Logik implementiert werden kann. Die Elemente der Sprache sind immer Layout-orientiert und der Umfang ist so gering, dass die Sprache mühelos in kürzester Zeit zu erlernen ist.

Logik und Programmierung sind – bis auf die Variablennamen – streng getrennt. Der Ansatz, ein Hashtable als Model zu verwenden, reduziert den Aufwand für den Programmierer gewaltig. Auch für die Verarbeitung von Webformularen gibt es unterstützende Funktionen, so kann über

iSize = (String) context.getForm("size");

der Wert des entsprechenden Eingabefelds ausgelesen werden. Das komplette Servlet, das die Webseite aus Listing 1 verarbeitet, kann sich wieder jeder von meiner Webseite [2] herunterladen.

Ein rudimentäres Raum-Reservierungssystem mit Webmacro (offensichtlich auch für Hilbert-Räume).

Velocity

Velocity ist ein Teil des Jakarta-Projekts. Es kann über [3] heruntergeladen werden, wird aber auch als Teil des weiter unten besprochenen Turbine-Frameworks ausgeliefert.

Zu Velocity ist sehr wenig zu sagen. Hier genügt ein Zitat aus dem Design-Dokument: “Velocity’s design concept is borrowed from WebMacro.” Die Skriptsprache von Velocity sieht der Sprache von Webmacro zwar zum Verwechseln ähnlich, ist aber keineswegs identisch, weshalb die Templates auch leider nicht austauschbar sind. Velocity hat einen etwas anderen Funktionsumfang, aber das betrifft nur Randbereiche.

Mir ist etwas unklar, warum es zwei fast identische Projekte gibt. Vielleicht liegt es an der unterschiedlichen Entstehungsgeschichte, da Webmacro nicht von Anfang an unter der GPL verfügbar war.

Turbine

Turbine (siehe [4]) wurde gerade eben schon erwähnt. Im Gegensatz zu Webmacro und Velocity setzt Turbine an etwas anderer Stelle an. Aus dem Wissen heraus, dass fast jede dynamische Website ähnliche Funktionalitäten benötigt, bietet dieses Framework verschiedene Tools rund um Web-Applikationen an: “A platform for building applications, not just running them.” Die Feature-Liste ist lang und enthält unter anderem Punkte wie die Integration mit Template-Systemen (Cocoon, Webmacro, Velocity und anderen), Database Connection Pooling, Unterstützung des MVC-Designpatterns, JNDI-Support, Logging und Caching.

Von Turbine gibt es noch keine Release, allerdings ein ständig aktualisiertes Turbine Development Kit, das neben einer Betaversion von Tomcat 4 (Codename Catalina) alle Tools enthält. Während der Download von Webmacro mit seinen weniger als 900 KByte recht schnell ist, benötigt das Turbine-Kit mehr als 6 MByte, ausgepackt sind es dann 38 MByte.

Ich halte den Ansatz von Turbine für nicht mehr zeitgemäß. Viele der Funktionen von Turbine werden besser über einen EJB-Server abgedeckt. Auch die Struktur, die Turbine über die Erzeugung von Webseiten legt, ist mir zu starr. So wird jede Seite in Layout, Navigation und Inhalt aufgeteilt. Für die Erzeugung dieser Komponenten ist jeweils eine eigene Sub-Klasse verantwortlich.

Oft mag diese Struktur richtig sein, aber immer dann, wenn die Navigation vom Inhalt abhängig ist, wird die Trennung problematisch und muss durch geeignete Klimmzüge überwunden werden. Gerade bei einfacheren Webseiten kommt es durch den Turbine-Ansatz zu einer Proliferation von Klassen und damit zu einer unnötigen Erhöhung der Komplexität.

Struts

Das sehr produktive Jakarta-Projekt stellt noch einen weiteren Ansatz für die Erstellung dynamischer Webseiten zur Verfügung. Struts hält sich dabei an die reine J2EE-Lehre, die JSP-Seiten mit Taglibs für dynamische Webseiten vorsieht. Struts steht kurz vor der 1.0-Release, aktuelle Versionen sind über die Struts-Homepage auf [5] verfügbar.

Der Ansatz von Struts ist es, das MVC-Paradigma auf einzelne Klassen abzubilden. Als Controller dient ein generisches Servlet ( ActionServlet), das über eine XML-Datei ( struts-config.xml) konfiguriert wird. Die Funktionalität dieses Servlets kann bei Bedarf durch eine Sub-Klasse erweitert werden.

Die Business-Logik wird durch eine Sub-Klasse von Action implementiert. Dabei handelt es sich in aller Regel um einen Wrapper zur eigentlichen Business-Logik, wie sie beispielsweise in EJBs vorhanden ist. Das Model wird durch eine Sub-Klasse von ActionForm repräsentiert. Dessen validate()-Methode ist unter anderem für die Überprüfung der Daten des zugehörigen Webformulars zuständig. Die View ist eine JSP-Seite, die über Tags auf Werte aus ActionForm zugreift.

Nach dem klassischen Motto “Teile und herrsche” wird also das Problem auf zwei Klassen ( Action und ActionForm) aufgeteilt, die über die Konfigurationsdatei struts-config.xml verbunden werden. Das erzeugt aber wieder zusätzliche Komplexität, die man erst mal verstehen muss.

Ein weiterer Nachteil könnte mangelnde Disziplin seitens der Webdesigner sein. JSP bietet ja die Möglichkeit, Java-Code in die Seite einzubetten. Für eine Struts-Anwendung ist das nicht notwendig, aber leider auch nicht zu verhindern. Damit würde der strikte MVC-Ansatz von Struts unterlaufen. Hier ist neben einem strengen Projektmanagement (einschließlich einer entsprechenden Qualitätssicherung) auch von Seiten der Programmierer eine gewisse Flexibilität notwendig um zu verhindern, dass die Designer es selber tun, weil die Programmierer keine Zeit haben.

Wer mehr über Struts erfahren möchte, sollte unbedingt das informative Tutorial auf der Developer-Works-Seite von IBM zu diesem Thema lesen (siehe [6]).

XMLC

XMLC, den XML-Compiler, möchte ich hier nur kurz erwähnen. Dieser Teil des Enhydra-Projekts ([7]) erzeugt aus HTML/XML-Dateien Java-Klassen, um über das DOM-Modell dynamische Seiten zu generieren. Damit gehört XMLC auch in die Kategorie der Template-basierten Systeme. In einem früheren Coffee-Shop habe ich ein Projekt vorgestellt, das XMLC verwendet ([8]).

XMLC ist sehr mächtig, allerdings ist auch die Lernkurve sehr steil. Aus heutiger Sicht gibt es beispielsweise mit Webmacro einfachere Lösungen.

WingS

Für GUI-Applikationen unter Java ist inzwischen Swing der Standard. Ein wenig umgestellt ergibt dies WingS, ein in alter Tradition rekursives Akronym für “WingS is net generation Swing”. Dieses GPL-Projekt der deutschen Firma Mercatis – Download unter [9] – versucht erfolgreich, die von Swing bekannte GUI-Sprache auf das Web zu übertragen.

Swing enthält nicht nur eine ganze Reihe von Widget-Klassen, sondern auch ein komplettes MVC-basiertes Framework für die Verarbeitung von Benutzereingaben wie Events und Event-Listener. Dieses Paradigma wird von WingS auf das Web übertragen. Unter Swing gibt es etwa die Klassen JComponent und JButton. Die analogen Klassen unter WingS lauten SComponent und SButton. Unter Swing wie auch unter WingS ist ein ActionEventListener für die ActionEvents eines Buttons zuständig. WingS verwendet dafür sogar dieselben Klassen aus den Swing-Packages.

Genauso wie ein Swing-Programmierer mit der Widget-Klasse und von Layout-Managern seine GUI aufbaut, baut der WingS-Programmierer sein Web-Interface auf. In Listing 2 ist ein Beispiel aufgeführt. Dieses Beispiel verwendet ein TemplateLayout. Die in den Zeilen 95 bis 99 erzeugten Controls werden dabei in ein Panel eingefügt (Zeilen 121 bis 124), dessen Layout durch eine HTML-Template-Seite bestimmt wird. WingS verwendet dafür in den HTML-Seiten das object-Tag.

Events werden durch einen entsprechenden Submit-Button ausgeführt und über einen ActionEventListener verarbeitet (Zeilen 101 bis 107). Der Programmtext könnte genauso in einer normalen Swing-Anwendung verwendet werden.

Der große Vorteil von WingS ist die Wiederverwendung einer bekannten Sprache für die Erzeugung und Verarbeitung von GUIs. Wer eine Swing-Applikation auf das Web portieren muss, sollte unbedingt einen Blick auf WingS werfen. Dieses Paket ist gewissermaßen die Sicht des Programmierers auf dynamische Webseiten. Über das Template-Layout können zudem auch Design und Programmierung getrennt werden, wie es auch bei den anderen Template-basierten Systemen möglich ist.

Der Funktionsumfang von WingS ist sehr groß. Gerade wer mit komplizierten Controls wie Tree-Views, Tabellen oder Tabbed-Panes arbeitet, wird WingS zu schätzen wissen – sogar ganz ohne HTML-Kenntnisse sind damit ansprechende Oberflächen zu gestalten. Ein weiterer Vorteil von WingS ist das wie unter Swing verfügbare pluggable Look & Feel. Über solch ein Look & Feel kann mit einem Befehl das Aussehen der gesamten Applikation auf die Fähigkeiten des jeweiligen Browsers abgestimmt werden. Gerade in diesem Punkt erweist sich WingS anderen Systemen klar überlegen.

WingS verwendet in der aktuellen Version eine Reihe von AWT-Klassen, zum Beispiel für Events, aber auch für die Image-Verarbeitung. Das macht zwar einerseits Sinn, weil dadurch keine Implementationsarbeit anfällt, andererseits wird deshalb für eine WingS-Anwendung stets ein X-Server benötigt. Unter Linux könnte hier der virtuelle Framebuffer zum Einsatz kommen.

Die Dokumentation zu WingS könnte besser sein, doch wird eine komplette Beispielanwendung mitgeliefert, die die Verwendung aller Controls vorführt. Durch klassisches Cut & Paste lassen sich damit eigene Anwendungen schnell erstellen. Vorbildlich an dem Beispiel ist die Tomcat-Integration. Mit minimalem Aufwand läuft das Beispiel innerhalb von Tomcat, ohne dass ein kompletter Tomcat-Server mitgeliefert wird – wie dies leider inzwischen von vielen Paketen gemacht wird.

> zipinfo -1 rrsystem.ear
META-INF/
META-INF/MANIFEST.MF
META-INF/application.xml
rrsystem-ejb.jar
rrsystem-cli.jar
rrsystem-web.war

> zipinfo -1 rrsystem-web.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/lib/
WEB-INF/lib/webmacro.jar
WEB-INF/lib/wings.jar
WEB-INF/classes/
WEB-INF/classes/WebMacro.properties
WEB-INF/classes/EditRoom.thtml
WEB-INF/classes/de/
WEB-INF/classes/de/bablokb/
WEB-INF/classes/de/bablokb/rrsystem/
WEB-INF/classes/de/bablokb/rrsystem/servlets/
WEB-INF/classes/de/bablokb/rrsystem/servlets/CreateRoom.class
WEB-INF/classes/de/bablokb/rrsystem/servlets/EditRoom.class
WEB-INF/classes/de/bablokb/rrsystem/servlets/EditRoom$1.class
WEB-INF/web.xml
index.html
CreateRoom.wm

02: #silence $message
03: <html>
04:   <head>
05:     <title>Room Reservation System</title>
06:   </head>
07:
08:   <body>
09:     <h1>Room Reservation System</h1>
10:
11:       <p><font color="blue">$message</font>
12:       </p>
13:
14:       <p>
15:    <FORM METHOD="POST" ACTION="CreateRoom">
16:      <TABLE ALIGN="CENTER">
17:        <tr>
18:          <td>
19:          <td>
20:        </TR>
21:        <tr>
22:          <td>
23:          <td>
24:        </TR>
25:        <tr>
26:          <td><INPUT TYPE="SUBMIT"
27:                       NAME="action"
28:                       VALUE="SUBMIT">
29:          </TD>
30:        </TR>
31:      </TABLE>
32:    </FORM>
33:       </p>
34:
35:     <hr>
41:   </body>
42: </html>

Barracuda

Barracuda (siehe [10]) ist ein Teil des Enhydra-Projekts und war früher unter dem Namen Rocks bekannt. Analog zu WingS strebt dieses Projekt eine auf den von Swing bekannten Implementationsmustern beruhende Lösung für die Erstellung von Web-Anwendungen an. Ein detaillierter Projektplan sowie eine Pre-Release ist schon verfügbar, bis zu einer Beta-version wird aber noch einige Zeit vergehen. Auf alle Fälle handelt es sich aber um ein sehr interessantes Projekt, dessen Fortschritt ich beobachten werde. Ein explizites Ziel von Barracuda ist auch die Integration von Javascript, erschließt dies doch einige Möglichkeiten für die Verarbeitung von Benutzereingaben schon auf Client-Seite.

ECS

Das Element Construction Set, kurz ECS, erwähne ich hier nur der Vollständigkeit halber. Auch dieses Projekt ist Teil von Jakarta und über [11] verfügbar. Das ECS kapselt alle HTML-Entitäten in eigenen Objekten. Das ECS ist also für alle interessant, die Webseiten dynamisch ausgeben wollen, ohne auf print-Statements zurückgreifen zu wollen. Gewissermaßen könnte ECS die Schicht unterhalb der oben besprochenen Toolkits bilden und für die eigentliche Ausgabe des HTML-Textes verantwortlich sein.

Freemarker

Freemarker (siehe [13]) ist auch ein mit der Funktionalität von Webmacro vergleichbares Toolkit. Allerdings ist Webmacro deutlich einfacher zu verwenden. Freemarker benötigt beispielsweise verschiedene Hashtable-Klassen, um mit Skalaren, Hashes, Listen und Objekten mit Methoden umzugehen. Webmacro erledigt das alles durch das Reflection-API transparent für den Programmierer. Auch um Dinge wie das Schreiben der erzeugten Seite in den Print Writer des Servlets oder um das Caching muss sich der Programmierer bei Freemarker selbst kümmern.

042: public class EditRoom  extends SessionServlet implements SConstants {
043:
091:   public void postInit(ServletConfig config) {
092:
093:     // create controls
094:
095:     iMsgLabel     = new SLabel(iMessage);
096:     iNameBox      = new SComboBox();
097:     updateNameBox();
098:     iSizeField    = new STextField();
099:     iChangeButton = new SButton("Change");
100:
101:     iChangeButton.addActionListener(new ActionListener() {
102:       public void actionPerformed(ActionEvent e) {
103:         queryForm();
104:         if (verifyForm())
105:           update();
106:         iMsgLabel.setText(iMessage);
107:       }
108:     });
109:
110:     // create panel with template layout
111:
112:     SForm panel = new SForm();
113:     try {
114:       java.net.URL url = this.getClass().getResource(TEMPLATE);
115:       STemplateLayout layout = new STemplateLayout(url);
116:       panel.setLayout(layout);
117:     }
118:     catch (java.io.IOException e) {
119:       e.printStackTrace();
120:     }
121:     panel.add(iMsgLabel,"message");
122:     panel.add(iNameBox,"roomComboBox");
123:     panel.add(iSizeField,"sizeEF");
124:     panel.add(iChangeButton,"changeButton");
125:
126:     SContainer contentPane = getFrame().getContentPane();
127:     contentPane.add(panel);
128:   }
201: }

finally{}

Die Anzahl der verschiedenen Projekte zeigt schon, dass es keinen Königsweg zur perfekten Website gibt. Die Vielfalt lässt ahnen, dass sich bisher noch kein Standard etabliert hat. Wer sich an den J2EE-Standard halten will beziehungsweise muss, dem empfehle ich Struts. Ansonsten sind WingS und Webmacro/Velocity sicherlich keine falsche Wahl.

In der Realität wird es aber wahrscheinlich so sein, dass auf einer höheren Abstraktionsebene programmiert wird. Je nachdem, ob es beispielsweise um Content- oder Dokumenten-Management geht, bieten sich weitere Pakete an, die zum Teil auch bereits im Linux-Magazin vorgestellt wurden. Die hier beschriebenen Toolkits sind dann die Basis für solche Implementationen.

Wahrscheinlich gibt es noch andere Projekte, die sich mit demselben Thema beschäftigen. Für entsprechende Hinweise bin ich immer dankbar, denn manchmal sind gerade die Perlen im Web schwer zu finden.

Mit dieser Folge verabschiede ich mich fürs Erste vom Thema Enterprise-Lösungen für Java. Ich hoffe, ich konnte ein paar Anregungen für den sinnvollen Einsatz von Java auf dem Server geben. In der nächsten Folge des Coffee-Shops geht es um Techniken für die Integration von Java mit Linux. ( uwo)