Home 
ORDIX News 1/2007 Java/J2EE
ORDIX News 1/2007 Java/J2EE
ORDIX News 1/2007 Java/J2EE
Bereich Web-Anwendungens-| JSF JavaServer Faces ist ein standardisiertes Framework zur Entwicklung von Web-Anwendungen. |
| JavaServer Pages Java-Komponente einer Web-Anwendung, die durch den J2EE-Standard definiert ist. Eine JSP ähnelt vom Aufbau einer HTML-Seite mit integriertem Java-Code. Sie wird zuerst vom Web-Container in ein Servlet kompiliert. Anschließend nimmt das Servlet Client-Anfragen in Form eines HTTP-Requests entgegen und generiert dynamisch eine Antwort, die es über einen HTTP-Response an den Client zurückschickt. |
Weiterführende Links
MyFaces [1] ist eine freie Standardimplementierung von JavaServer Faces. Die Bedienelemente, die eine Standardimplementierung zur Verfügung stellt, befriedigen aber in den seltensten Fällen die Anforderungen an eine Benutzeroberfläche.
Selbstverständlich ist JavaServer Faces erweiterbar, doch sollte es nicht Aufgabe der Anwendungsentwicklung sein, neue Bedienelemente zu entwerfen. Im Gegenteil: Als Grundlage der Anwendungsentwicklung sollte eine Implementierung ausgesucht werden. Die Bedienelemente dieser Implementierung sollten ausreichen, um die Anforderungen an die Benutzeroberfläche zu erfüllen.
In dem Open Source Projekt MyFaces wird Tomahawk als eine Erweiterung von JavaServer Faces angeboten. Die Möglichkeiten der Bedienelemente können in [2] ausprobiert werden. In diesem Artikel wird beispielhaft der Umgang mit einigen Tomahawk-Bedienelementen dargestellt. Beispiele und Quellcode stammen in wesentlichen Teilen aus den Open Source Projekten Tomahawk und MyFaces.
Oftmals werden Web-Anwendungen als Intranet-Anwendungen dafür verwendet, Ergebnisse von Datenbank-Abfragen darzustellen. Das führt zu wiederkehrenden Anforderungen: Die Ergebnisse sollen - das liegt nahe - als Tabellen dargestellt werden.
Zur Verbesserung der Übersicht werden die Daten seitenweise dargestellt: Bei größeren Datenmengen wird der Benutzer blättern, um mehr Information zu bekommen. Neben dem Blättern steht häufig die Sortierung der Ergebnisse nach Spalten ganz oben auf der Wunschliste.
Manchmal reicht das aber noch nicht: In manchen Fällen müssen die Ergebnisse veränderbar sein. Die Zellen der Tabelle bestehen dann aus Eingabefeldern.
Für diese Standard-Anforderung werden von Tomahawk die Elemente dataTable und dataScroller zur Verfügung gestellt. Ein Ergebnis könnte beispielsweise wie in Abbildung 1 aussehen.
 |
| Abb. 1: Typische Tabelle mit Sortier- und Editiermöglichkeit. |
Hier werden einige Eigenschaften eines Autos ausgegeben. Die Spaltenüberschriften sind teilweise als Link ausgeführt: Wird der Link betätigt, findet eine Sortierung der Tabelle nach dieser Spalte statt. Wird nochmals auf die Spaltenüberschrift geklickt, so kehrt sich die Sortierreihenfolge um.
Die Spalte "Farbe" besteht aus Eingabefeldern. Hier kann der Benutzer die Werte beliebig verändern. Unterhalb der Tabelle finden sich die üblichen Elemente zum Blättern.
Um so eine Tabelle zu erstellen, muss der Entwickler einerseits eine Java Server Page und andererseits passende Managed Beans programmieren. Grundlagen zu JavaServer Faces werden in [4] dargestellt. Die folgenden Ausführungen skizzieren die erforderlichen Schritte der Entwicklung.
Die Darstellung wird durch eine Java Server Page realisiert. Den entsprechenden Code finden Sie in der separaten Datei, da er sehr lang ist (RTF, 9 KB).
Für die Nutzung der Tag-Bibliotheken von Tomahawk wird der Namensraum "t" verwendet:
<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
Die Darstellung der Tabelle erfolgt durch das Element dataTable. Die Formatierung der Tabelle wird weitgehend durch Cascading Stylesheets durchgeführt, die durch styleClass, headerClass, footerClass etc. referenziert werden. Die äußere Gestaltung lässt sich dadurch erheblich beeinflussen.
Wesentliche Attribute des Elements dataTable sind:
Im Folgenden werden die Spaltenüberschriften sowie die anzuzeigenden Felder definiert. Für sortierbare Spalten werden die Spaltenüberschriften in das Element commandSortHeader eingebettet. Wichtig ist dabei das Attribut columnName. Dieses Attribut gibt den Namen an, der für die Sortierspalte angezeigt wird.
Die Eingabefelder in der Tabelle werden einfach durch ein inputText-Element definiert. Die Funktionalität des Blätterns stellt das Element dataScroller zur Verfügung. Die Abhängigkeit zwischen diesem dataScroller-Element und der Tabelle wird durch das Attribut for definiert.
Die erforderlichen Elemente lassen sich in der Java Server Page schnell definieren. Aus der Perspektive der Entwicklung ist eine solche Seite schnell erstellt.
Es darf jedoch nicht verkannt werden, dass der wesentliche Teil der Aufwände einer solchen Seite nicht bei der Entwicklung sondern bei der Gestaltung liegt. Diese ist glücklicherweise durch die Verwendung von Stylesheets gut gekapselt. So kann die Gestaltung unabhängig von der Entwicklung durchgeführt werden.
Die Managed Bean ist die Schnittstelle zur Java Server Page. Im Beispiel in Abbildung 2 heißt sie pagedSort. Aufgabe der Managed Bean ist es, die Daten für die Darstellung zu liefern. In einer realen Anwendung würde die View die Daten aus dem Domain Model holen. In dem Beispiel werden die Daten stattdessen im Konstruktor erzeugt.
| Den Code zu Abbildung 2 finden Sie in der separaten Datei, da er sehr lang ist (RTF, 9 KB). |
| Abb. 2: Java Server Page zur Darstellung einer sortierbaren Tabelle mit Eingabefeldern. |
Im Folgenden sollen die erforderlichen Methoden der Managed Bean betrachtet werden, die für das Verhalten der sortierbaren Tabelle implementiert werden müssen. Die "schlechte Nachricht" dabei ist, dass das Sortieren in der Managed Bean zu implementieren ist. Die "gute Nachricht": die Aufgabe ist nicht so schwierig zu lösen.
Die Parameter der Sortierung sind die Spalte, nach der die Sortierung erfolgen soll, und die Sortierreihenfolge. Die Spalteninformation ist in dem Attribut sort, die Reihenfolge der Sortierung in dem Attribut ascending abgelegt. Die eigentliche Sortierung erfolgt immer dann, wenn die Liste der Autos herausgegeben wird.
| Den Code zu Abbildung 3 finden Sie in der separaten Datei, da er sehr lang ist (RTF, 2 KB). |
| Abb. 3: Schnittstellen-Methoden der Managed Bean zur Java Server Page. |
In Abbildung 3 sind die Schnittstellen-Methoden zur Java Server Page abgedruckt.
Die Verarbeitung der eingegebenen Daten erfolgt über die Methode setCars. Diese Methode wird nach jedem Request aufgerufen. Die übergebene Liste enthält den Ausschnitt der Daten, der auf der Seite dargestellt und gegebenenfalls editiert wurde. Ob die Daten vom Benutzer verändert wurden, kann in der Methode setCars durch einen Vergleich der Objekte ermittelt werden. Im Listing werden die übergebenen Informationen einfach als neue Objekte in die Bestandsliste eingefügt. Die alten Elemente werden gelöscht.
Dieser Komfort bei der Programmierung editierbarer Listen ist in JavaServer Faces Implementierungen verbreitet. Zu diesem Zweck werden Objekte, die für die interne Repräsentation des Dialogs verwendet werden, server- oder client-seitig gespeichert, um nach dem Request wieder rekonstruiert zu werden.
Da die Programmierung einer sortierbaren Tabelle mit Eingabefeldern zum Standardrepertoire einer Web-Anwendung gehört, ist die Frage nach dem Realisierungsaufwand berechtigt. Innerhalb von wenigen Personenstunden ist so eine Tabelle zu erstellen und mit Leben zu füllen. Aufgrund der klaren Struktur ist der Wartungsaufwand bedeutend geringer als bei einer typischen Web-Anwendung mit Struts.
 |
| Abb. 4: Ein Baum als Menü. |
Neben den vielen Bedienelementen, die Tomahawk anbietet, ist die Darstellung der Baumstruktur, wie man sie beispielsweise aus dem Explorer kennt, besonders gelungen (siehe Abbildung 4). Der Baum verfügt über die übliche Funktionalität: Äste können aus- und eingeklappt werden. In der Regel wird durch das Anklicken eines "Blattes" die Auswahl getroffen.
Bei der Realisierung kann die Grundfunktionalität des Auf- und Zuklappens der Äste entweder mit JavaScript oder durch den Server erfolgen. Reizvoll an der JavaScript-Möglichkeit ist, dass nach der Benutzeraktivität kein Request ausgelöst wird: Beim Auf- oder Zuklappen wird das Bild nicht neu aufgebaut. Die JavaScript-Variante wird daher auch standardmäßig verwendet.
Die Realisierung des Baums sollte mit dem Element tree2 erfolgen. Dieses bietet die Möglichkeit, unterschiedliche Knotentypen in unterschiedlicher Darstellung zu definieren. Ein Ausschnitt der Java Server Page ist in Abbildung 5 dargestellt.
Zur Darstellung wird dem Element tree2 durch das value-Attribut die Methode mitgeteilt, die eine Baumstruktur zurückliefert. Die Variable, über die der einzelne Knoten verfügbar gemacht wird, ist als Attribut var mit node definiert worden.
| Den Code zu Abbildung 5 finden Sie in der separaten Datei, da er sehr lang ist (RTF, 5 KB). |
| Abb. 5: Java Server Page zur Darstellung eines Baums. |
Beim tree2-Element erfolgt darauf für jeden Knotentyp die Definition der Darstellung. Als Typ sind in Abbildung 5 person und document dargestellt. Der Knotentyp document ist in dem Beispiel ein Blatt. An ihm hängen keine weiteren Knoten. Wird dieser Knotentyp ausgewählt, so erfolgt normalerweise eine Aktion. Die Aktion wird mit einfachen JSF-Mitteln getriggert. Um die Darstellung wird ein commandLink-Element gelegt. Das Attribut actionListener definiert die auszuführende Methode.
| Den Code finden Sie in der separaten Datei mit Abbildung 6 (RTF, 2 KB). |
| Abb. 6: Definition der Baumstruktur in der Managed Bean. |
Der Baum wird durch eine Managed Bean erstellt. Abbildung 6 zeigt Ausschnitte aus der Methode getTreeData, die in der Java Server Page zur Ermittlung der Baumstruktur aufgerufen wird.
Wesentlich dabei ist, dass diese Methode ein Objekt vom Typ TreeNode zurückgibt. Verwendet werden für die einzelnen Knoten Objekte vom Typ MyTreeNodeBase. Diese individualisierten Knoten haben den einzigen Zweck, auf die Auswahl des Benutzers zu reagieren. Die Methode selected kann als ActionListener verwendet werden. Auf diese Weise kann direkt bei einem Knoten Funktionalität hinterlegt werden.
Die Implementierung eines Baumes in eine Web-Anwendung mit Tomahawk stellt somit eine komfortable Lösung dar. Die Trennung von Darstellung und Funktionalität ist gelungen. Die Entwicklung wird gut unterstützt und der Code ist nachvollziehbar.
Die Liste der Bedienelemente, über die der Entwickler dank Tomahawk verfügt, ist beachtlich. Aufgrund des Umfangs sei hier nochmals auf [2] verwiesen, wo man sich über Aussehen und Handhabung unmittelbar informieren kann.
Neben der beeindruckenden Präsentation der Möglichkeiten darf jedoch nicht unerwähnt bleiben, was zunächst nicht offensichtlich ist. Bereits nach kurzer Zeit wird der potentielle Tomahawk-Anwender feststellen, dass Informationen rar sind. Der Informationsmangel ist bereits auf der Homepage von MyFaces [1] unübersehbar: Beschreibungen sind nur in Ansätzen verfügbar, Verweise zum Download des Beispiel-Pakets [5] oder zu den zugehörigen Quellen fehlen gänzlich.
Das wäre zu verschmerzen, wenn instruktive Informationen im JavaDoc oder gar ein Tutorial zur Verfügung stünden. Da beides nicht der Fall ist, ist der Quellcode unverzichtbar. Die Entwicklergemeinde ist nicht so groß, dass konkrete Fragen durch eine Internet-Recherche beantwortet würden.
Dennoch ist der Reiz der Möglichkeiten durch Tomahawk und JavaServer Faces groß: Der Produktivitätsschub gegenüber dem Framework Struts ist leicht ersichtlich. Der Aufwand für die Einarbeitung in JavaServer Faces und Tomahawk ist bei der Planung zu berücksichtigen.
Den Einstieg in die Entwicklung von Web-Anwendungen können wir Ihnen erleichtern: Zum Thema JavaServer Faces bietet ORDIX einen 5-tägigen Workshop an. Die Inhalte des Workshops finden Sie online im ORDIX Trainingsshop unter http://training.ordix.de.
Dr. Stefan Koch (info@ordix.de).