JavaServer Faces. Bernd Müller. Ein Arbeitsbuch für die Praxis ISBN Leseprobe

Transkript

1 JavaServer Faces Bernd Müller Ein Arbeitsbuch für die Praxis ISBN Leseprobe Weitere Informationen oder Bestellungen unter sowie im Buchhandel

2 Kapitel 3 Der Anwendungsprototyp Ein Arbeitsbuch für die Praxis darf JavaServer Faces nicht durch eine (unzusammenhängende) Aneinanderreihung von Beschreibungen einzelner Spracheigenschaften und Konzepte einführen, sondern muss anhand einer realistischen Aufgabe die gebotenen JSF-Mittel zu deren Lösung einsetzen. In diesem Kapitel werden wir für die imaginäre JSF-Bank die Anwendung Online-Banking als Prototyp entwickeln, die in stark simplifizierter Art Teile eines realen Online- Bankings nachbildet. Ziel ist die Erstellung einer kompletten Anwendung, die bereits möglichst viele Teile der JSF-Spezifikation verwendet, ohne für den JSF-Anfänger zu komplex zu werden. Nach einer ausführlichen Darstellung von JavaServer Faces im nächsten Kapitel und einer Vorstellung der in Java- Server Faces verfügbaren UI-Komponenten in Kapitel 5 wird der Protoyp in Kapitel 6 dann umfassend überarbeitet. 3.1 Anwendungsfälle Unser Ziel ist die Entwicklung einer kompletten Anwendung, die allerdings noch nachvollziehbar und damit nicht zu komplex sein soll. Um dies zu erreichen, müssen wir uns in der Funktionalität beschränken. Der Prototyp soll fünf einfache Anwendungsfälle umfassen, die wir kurz beschreiben. Anmeldung Ein Benutzer meldet sich mit Kundennummer und Kennwort an. Eine erfolgreiche Anmeldung ist Voraussetzung für die weiteren Anwendungsfälle.

3 22 3 Der Anwendungsprototyp Pflege der Stammdaten Im Falle eines Umzugs, einer Heirat mit Namensänderung etc. soll der Kunde seine Stammdaten selbst aktualisieren können. Überweisung durchführen Das eigentliche Bankgeschäft: Überweisung eines bestimmten Betrages von einem eigenen Konto auf ein beliebiges anderes Konto. Anzeige der Umsätze Für ein auszuwählendes Konto werden alle Umsätze angezeigt. Anzeige der Kurzinformationen zu allen Konten Die Kontostände aller Konten werden angezeigt. 3.2 Technische Architektur JavaServer Faces wird man in Zukunft sicher häufig als GUI-Komponente von Java-EE-Anwendungen einsetzen. Die Business-Objekte einer Java-EE- Anwendung werden in der Regel mit Enterprise-JavaBeans implementiert. JavaServer Faces sind aber nicht an die Verwendung von EJBs gebunden, sondern können mit beliebigen Java-Objekten, insbesondere auch mit POJOs (Plain Old Java Objects), verwendet werden. Unser Projekt Online-Banking wird mit POJOs entwickelt. Diese werden mit Hilfe eines Object-Relational-Mappers (OR-Mapper) auf eine relationale Datenbank abgebildet. Es ergibt sich eine technische Architektur, die strukturell in Abbildung 3.1 dargestellt ist. Java- Servlet Container JSF POJO Browser DB HTTP HTTPS View Controller Business Modell Persistenz Abbildung 3.1: Architektur des Prototyps Server Faces realisieren die Kommunikation mit dem Browser. Der Prototyp verwendet als Protokoll HTTP. Eine reale Online-Banking-Anwendung würde HTTPS verwenden. Das Business-Modell ist mit einfachen Java-Klassen

4 3.3 Das Business-Modell 23 realisiert, die über eine Persistenzschicht auf Tabellen einer relationalen Datenbank abgebildet werden. In diesem Kapitel gehen wir auf Probleme des OR-Mappings nicht detaillierter ein, sondern verweisen auf Abschnitt 6.4. JavaServer Faces werden durch Servlets, genauer durch ein Servlet, realisiert. Für den Betrieb einer JSF-Anwendung benötigt man daher einen Servlet- Container. Wir verwenden hier Tomcat, den Servlet-Container der Apache Software Foundation. Tomcat ist die offizielle Referenzimplementierung der Servlet-Spezifikation, weit verbreitet und zudem unentgeltlich sowohl privat als auch kommerziell verwendbar. Als Persistenzschicht kommt Hibernate zum Einsatz. Als Datenbankmanagementsystem verwenden wir das in Java geschriebene und somit auf praktisch jedem Rechner lauffähige HSQLDB. Es kann so konfiguriert werden, dass es nach dem Deployment der Web-Anwendung sofort läuft, so dass aufwändige Installationen, Konfigurationen und insbesondere Datenimporte unnötig sind. 3.3 Das Business-Modell Das Business-Modell des Online-Bankings ist ebenfalls stark simplifiziert. Leser, die bereits ähnliche Systeme erstellt haben, mögen dies verzeihen. Für Lehr- und Lerninhalte zum Thema JavaServer Faces reicht das einfache Business-Modell aber aus. Das Modell enthält Kunden, Konten und ein Transaktionslog. Bei den Konten wird zwischen Giro- und Sparkonten unterschieden. Das entsprechende UML-Klassendiagramm ist in Abbildung 3.2 auf der nächsten Seite dargestellt. Im Folgenden gehen wir davon aus, dass die fünf Business-Klassen wie dargestellt als JavaBeans existieren. Die Attribute jeder Klasse besitzen entsprechende Getter und Setter, und die Assoziationen sind als Methoden Kunde.getKonten(), Konto.getKunde() sowie Konto.getTransaktionen() und Transaktionslog.getKonto() verfügbar. 3.4 Realisierung Die fünf Anwendungsfälle aus Abschnitt 3.1 realisieren wir mit fünf JSF-Seiten. Dies muss nicht immer so sein, wird aber oft zutreffen. Anwendungsfälle, die komplexe Workflows umfassen, werden in der Regel über mehrere JSF-Seiten definiert. Dieses Kapitel dient als Demonstration einer funktional einfachen, aber kompletten Anwendung. Es werden daher nicht alle Einzelheiten im Detail er-

5 24 3 Der Anwendungsprototyp Kunde Konto Transaktionslog -vorname:string -nachname:string -geburtsdatum:date -geschlecht:character -strasse:string -plz:string -ort:string 1 1..* konto -kontostand:bigdecimal 1 0..* transaktionen -betrag:bigdecimal -art:character -datum:date -text:string Sparkonto -zinssatz:bigdecimal Girokonto -ueberziehungskredit:bigdecimal -zinssatzkredit:bigdecimal -zinssatzguthaben:bigdecimal Abbildung 3.2: UML-Klassendiagramm für den Prototyp läutert. Eine detailierte Gesamtdarstellung der Möglichkeiten von JavaServer Faces finden Sie in Kapitel 4, eine Gesamtdarstellung der JSF-Tags im Anhang A Die Anmeldung Für die Anmeldung wird die Kundennummer und das Kennwort benötigt. Genügen beide den Authentifizierungsregeln, so wird der Benutzer in die eigentliche Anwendung weitergeleitet, sonst ist eine Meldung über die missglückte Anmeldung anzuzeigen. Listing 3.1 zeigt die JSF-Seite login.jsp für die Anmeldung. Listing 3.1: Die Seite login.jsp 1 <%@ page session =" false " contenttype =" text / html ; charset = utf-8 "%> 2 <%@ taglib uri =" http: // java. sun. com / jsf / html " prefix ="h"%> 3 <%@ taglib uri =" http: // java. sun. com / jsf / core " prefix ="f"%> 4 5 <! DOCTYPE HTML PUBLIC "-// W3C // DTD HTML 4.01 Transitional // EN" > 6 <html > 7 file =" include / head. inc "%> 8 <body > 9 <f:view > 10 <h:form id=" form " style =" margin: 100 px;"> 11 < h: panelgrid columns =" 2" styleclass =" bordertable "

6 3.4 Realisierung headerclass =" panelheading " > 13 < f:facet name =" header "> 14 < h: outputtext value =" Anmeldung Online- Banking " / > 15 </ f:facet > 16 < h: outputlabel for =" kundennummer " value =" Kundennummer: " / > 17 < h: inputtext id =" kundennummer " 18 value ="#{ kundenhandler. kundennummer " / > 19 < h: outputlabel for =" kennwort " value =" Kennwort: " / > 20 < h: inputsecret id =" kennwort " 21 value ="#{ kundenhandler. kennwort " /> 22 < h: commandbutton action ="#{ kundenhandler. login " 23 value =" Anmelden " /> 24 < h: panelgroup / > 25 </ h: panelgrid > 26 </ h:form > 27 </ f:view > 28 </ body > 29 </ html > In den Zeilen 2 und 3 werden die beiden JSF-Tag-Bibliotheken bekannt gemacht. Tag-Bibliotheken sind eine Spracheigenschaft der JavaServer Pages (JSP), die für JavaServer Faces als Default-Implementierung verwendet werden. Die beiden Präfixe, in diesem Fall h und f, sind beliebig wählbar, man sollte jedoch der üblichen Konvention folgen und diese beiden Buchstaben wählen. Die erste JSF-Komponente ist <f:view>. Diese ist ein Container, das heißt, sie kann andere Komponenten enthalten. Jede JSF-Seite muss als Wurzel eine View enthalten, die alle anderen JSF-Komponenten enthält. Die nächste Komponente ist <h:form>. Diese wird nach dem Rendern in HTML zu einem HTML-Formular. Die Komponente <h:panelgrid> ist ebenfalls ein Container und ordnet ihre eingebetteten Komponenten in Tabellenform an. Dazu wird lediglich die Anzahl der Spalten spezifiziert, die Definition einzelner Zeilen ist nicht möglich. Ein Panel-Grid enthält optional eine Überschrift, die mit der <f:facet>-komponente und Attribut name="header" in Zeile 13 festgelegt wird. Die weiteren, zum Teil mehrfach verwendeten Komponenten sind <h:outputtext>, <h:outputlabel> und <h:inputtext>, die eine Textausgabe, ein Label und ein Eingabefeld erzeugen. Die <h:inputsecret>- Komponente ist eine Eingabekomponente, die den eingegebenen Text jedoch nicht anzeigt und daher in der Regel zur Passworteingabe verwendet wird. Schließlich erzeugt <h:commandbutton> eine Schaltfläche, deren Betätigung zum Aufruf einer Action-Methode führt. Die <h:panelgroup>-komponente wird verwendet, um mehrere Komponenten zusammenzufassen. Hier wird sie als Platzhalter verwendet, um in der letzten Zeile der Tabelle die zweite Spalte zu füllen.

7 26 3 Der Anwendungsprototyp Auch ohne detaillierte Kenntnis der einzelnen Komponenten ist diese JSF-Seite recht gut verständlich, und die aus ihr entstehende HTML-Seite kann bereits erahnt werden. Die entsprechende Darstellung im Browser ist in Abbildung 3.3 dargestellt. Abbildung 3.3: Browserdarstellung von login.jsp Interessant ist nun, wie die JSF-Seite mit dem Java-Handler für diese Seite verbunden wird. Aus der JSF-Seite geht hervor, dass eine JavaBean kunden- Handler mit den Properties kundennummer und kennwort sowie der Action- Methode login verwendet wird. Die Bean ist eine Instanz der in Listing 3.2 dargestellten Klasse KundenHandler. Diese Art Bean wird in der Originalliteratur auch Backing-Bean genannt. Listing 3.2: Die Managed-Bean KundenHandler /** * Nach einem erfolgreichen Login merkt sich die * KundenHandler - Instanz den Kunden. */ public class KundenHandler { private String kundennummer ; private String kennwort ; private Kunde kunde ; // Der Kunde, global fuer Session private List konten ; // Konten dieses Kunden private List kontenitems ; // Zur Anzeige in Auswahlmenues public String login () {

8 3.4 Realisierung 27 // in der Version 1.0 ein wenig vereinfacht if ( kundennummer. equals (" 0815 ") && kennwort. equals (" geheim ")) { kunde = new KundeDAO (). getkundebyid (1111); konten = new ArrayList ( kunde. getkonten ()); return " success "; else { return " failure "; public List getkontenitems () { if ( this. kontenitems == null ) { List kontenitems = new ArrayList (); for ( Iterator i = konten. iterator (); i. hasnext ();) { Konto tmp = ( Konto ) i. next (); kontenitems. add ( new SelectItem ( tmp, KontoConverter. getasstring ( tmp ))); this. kontenitems = kontenitems ; return this. kontenitems ; // ab hier nur einfache Getter und Setter Für den Anmeldevorgang sind nur die Properties kennwort, kundennummer und kunde mit den nicht dargestellten Gettern und Settern sowie die Methode login() interessant. Die beiden erstgenannten Properties sind durch JSF- EL-Ausdrücke an die beiden <h:inputtext>-komponenten gebunden. Man könnte auch sagen, dass die beiden Komponenten an die Properties gebunden sind. Da die Bindung aber bidirektional ist, ist beides richtig. Wenn die login-methode aufgerufen wird, stehen in den beiden Properties bereits die korrekten Werte des HTML-Formulars. In der Bedingung der If-Verzweigung kann daher getestet werden, ob die Kundennummer 0815 und das Kennwort geheim ist. Dieser sehr einfache Fall ist dem einführenden Charakter dieser Authentifizierung geschuldet. In Kapitel 6 wird die Authentifizierung nach dem in der Servlet-Spezifikation festgelegten Verfahren vorgenommen. Falls die Eingaben von Kundennummer und Kennwort die verlangten Werte haben, wird den Variablen kunde und konten ein Wert zugewiesen und die Methode mit einem Return-Wert von "success" beendet. Wenn nicht, gibt die Methode "failure" zurück. Die Variable kunde bekommt ein Kundenobjekt zugewiesen, das der Klasse Kunde des Klassendiagramms aus Abbildung 3.2 entspricht.

9 28 3 Der Anwendungsprototyp Wir wollen uns an dieser Stelle auf den Umgang mit JavaServer Faces konzentrieren, so dass wir auf die Klasse KundeDAO nicht näher eingehen. Wir verweisen auf Abschnitt 6.4, in dem das so genannte Data-Access-Object-Pattern (DAO) eingehend erläutert wird. Die Methode login() hat einen Rückgabewert vom Typ String. Eigentlich würde man für eine Methode, die durch die Betätigung eines Knopfes aufgerufen wird, eher void oder boolean erwarten. Der Grund für die Verwendung von String ist, dass Action-Methoden vom Laufzeitsystem zur Navigation verwendet werden. Im einführenden Tic-Tac-Toe-Spiel haben wir hiervon keinen Gebrauch gemacht und immer dieselbe Seite angezeigt. Hier soll jedoch abhängig vom Ausgang des Anmeldeversuchs der Benutzer entweder in die eigentliche Anwendung geleitet werden oder eine Seite mit der entsprechenden Information über die missglückte Anwendung angezeigt bekommen. Die Konstante "success" zeigt den geglückten, failure den missglückten Anmeldeversuch an. Wo wird nun der zurückgegebene String verwendet? JavaServer Faces realisiert die Navigation über eine deklarative Beschreibung, die vom so genannten Navigation-Handler interpretiert wird. Basis sind (unter anderem) die von Action-Methoden zurückgegebenen Werte. Die Beschreibung selbst geschieht in der Konfigurationsdatei faces-config.xml, in der auch die Managed-Beans deklariert werden. Der entsprechende Ausschnitt der Konfigurationsdatei für die Navigation der Login-Seite ist in Listing 3.3 dargestellt. Listing 3.3: Navigationsteil der Konfigurationsdatei faces-config.xml < navigation- rule > < description > Das Login </ description > < from-view-id >/ pages / login. jsp </ from-view-id > < navigation- case > < from-outcome > success </ from-outcome > < to-view-id >/ pages / kontenuebersicht. jsp </ to-view-id > </ navigation- case > < navigation- case > < from-outcome > failure </ from-outcome > < to-view-id >/ pages / login. jsp </ to-view-id > </ navigation- case > </ navigation- rule > Ohne im Detail die einzelnen Elemente zu erläutern (dies geschieht in Abschnitt 4.6), sind mit <from-view-id>, <from-outcome> und <to-view-id> schnell die Elemente identifiziert, die für eine gegebene Seite und den Rückga-

10 3.4 Realisierung 29 bewert einer Action-Methode die neue aktuelle Seite bestimmen. Im vorliegenden Fall wird durch einen Rückgabewert "success" zur Seite kontenuebersicht.jsp verzweigt, bei einem Rückgabewert von failure wird die Seite login.jsp erneut angezeigt. Das erneute Darstellen derselben Seite ist der Default-Fall der Navigation, so dass die Angabe entfallen könnte. Als letzter Teil bleibt noch die Deklaration der Managed-Bean kundenhandler. Die Deklaration einer Managed-Bean erfolgt, wie wir bereits beim Tic-Tac- Toe-Spiel gesehen haben, in derselben Konfigurationsdatei. Der entsprechende Ausschnitt ist in Listing 3.4 dargestellt. Wichtig ist der auf session gesetzte Scope. Jede Session hat daher ihr eigenes KundenHandler-Bean. Listing 3.4: Die Managed-Bean kundenhandler < managed-bean > < managed- bean- name > kundenhandler </ managed- bean- name > < managed-bean-class > de. jsfpraxis. bank. handler. KundenHandler </ managed- bean- class > < managed-bean-scope > session </ managed-bean-scope > </ managed-bean > Validierung der Anmeldedaten Die Kundennummer und das Kennwort werden durch die Methode login() semantisch validiert. Eine syntaktische, zum Teil sogar ebenfalls semantische Validierung kann aber auch durch die JSP-Implementierung selbst vorgenommen werden und somit viele Routineprüfungen überflüssig machen. Im Falle der Anmeldedaten sind sowohl Kundennummer als auch Kennwort Pflichtangaben, das heißt, ein leeres Eingabefeld für diese beiden Daten ist als Fehlerfall zu werten. Im Augenblick gibt die login-methode den String "failure" zurück, und die Navigationsregel besagt, dass dann noch einmal die Login-Seite angezeigt wird, allerdings ohne weitere Information für den Benutzer. Eine entsprechende Fehlermeldung wäre hier angebracht. JavaServer Faces verfügt als einfachste Form der Validierung über den Test auf eine zwingend notwendige Eingabe, aber auch über eine Reihe komplexerer Tests. Der Test auf eine notwendige Eingabe wird durch das boolesche Attribut required deklariert. Die Verwendung des Attributes mit dem Wert true führt aber lediglich dazu, dass die weitere Bearbeitung der Seite unterbleibt und die Methode login erst gar nicht aufgerufen wird. Details über die einzelnen Bearbeitungsschritte einer JSF-Requests werden in Abschnitt 4.1 erläutert. Um

11 30 3 Der Anwendungsprototyp eine Meldung an den Benutzer zu erzeugen, wird die Meldungs-Komponente verwendet. Diese existiert in zwei Formen: <h:message> und <h:messages>. Die erste Form erzeugt eine Meldung für eine bestimmte Komponente, die zweite erzeugt Meldungen für alle Komponenten einer JSF-Seite. Wir verwenden die erste Form. Für die Zuordnung zu einer Eingabekomponente wird das for-attribut verwendet. Um das zweispaltige Layout der Anmeldung nicht zu zerstören, müssen die Meldungen und die Eingaben zusammengefasst werden. Hier kommt das Tag <h:panelgroup> zum Einsatz. Listing 3.5 zeigt den Ausschnitt aus der überarbeiteten Login-Seite. Listing 3.5: Login-Seite mit Fehlermeldung 1 < h: outputlabel for =" kundennummer " value =" Kundennummer: " / > 2 < h:panelgroup > 3 < h: inputtext id =" kundennummer " required =" true " 4 value ="#{ kundenhandler. kundennummer " /> 5 < h: message for =" kundennummer " / > 6 </ h: panelgroup > 7 < h: outputlabel for =" kennwort " value =" Kennwort: " / > 8 < h:panelgroup > 9 < h: inputsecret id =" kennwort " required =" true " 10 value ="#{ kundenhandler. kennwort " /> 11 < h:message for =" kennwort " /> 12 </ h: panelgroup > Bleibt bei der überarbeiteten Seite eines der beiden Eingabefelder leer, wird die entsprechende Fehlermeldung für die Message-Komponente erzeugt. Abbildung 3.4 zeigt die Darstellung im Browser, wenn beide Felder bei der Betätigung der Schaltfläche leer sind. Der Fehlertext wird in englischer Sprache dargestellt, was nicht sonderlich befriedigend ist. Weil Java von Haus aus bereits viele Möglichkeiten der Lokalisierung mitbringt, bauen JavaServer Faces hierauf auf und erlauben es, mit relativ wenig Aufwand Anwendungen zu lokalisieren. Eine Möglichkeit ist die Verwendung des locale-attributs im <f:view>-tag: < f:view locale =" Locale. GERMAN "> Alternativen für die Lokalisierung auf Anwendungs- und nicht auf Seitenebene werden in Abschnitt 4.7 dargestellt. Nach dieser Änderung wird die Seite bei fehlenden Eingaben wie in Abbildung 3.5 dargestellt.

12 3.4 Realisierung 31 Abbildung 3.4: Originalfehlermeldungen Abbildung 3.5: Fehlermeldungen mit deutscher Lokalisierung Während der Entwicklung einer JSF-Seite empfehlen wir die Verwendung des Tags <h:messages> z. B. am Ende der Seite. So werden alle auftretenden Fehler auch tatsächlich angezeigt. Wir werden in Abschnitt 4.4 noch weitere Möglichkeiten der Validierung kennen lernen Pflege der Stammdaten Der Anwendungsfall Pflege der Stammdaten ermöglicht es Bankkunden, ihre Stammdaten selbst zu aktualisieren, z. B. nach einem Umzug oder nach einer Namensänderung. Die entsprechende JSF-Seite ist typisch für die Stammdatenverwaltung und wird in abgewandelter Form häufig in betrieblichen Informationssystemen Verwendung finden. Wir stellen hier zunächst die Seitendar-

13 32 3 Der Anwendungsprototyp stellung vor, um danach die entsprechenden JSF-Elemente zu ihrer Entwicklung zu erarbeiten. Abbildung 3.6: Seite für den Anwendungsfall Pflege der Stammdaten Abbildung 3.6 zeigt die zu erstellende Seite zur Pflege der persönlichen Daten. Man erkennt bereits die Tabellenform, die typische zeilenweise Beschriftung und Eingabe-Anordung sowie eine Schaltfläche zum Abspeichern von Änderungen. Ebenfalls zu erkennen ist die Menüführung auf der linken Seite. Die JSF- Spezifikation kennt in der Version 1.1 keine Menükomponente. Wir verwenden hier jedoch MyFaces. In dieser Implementierung ist eine Menükomponente vorhanden, die wir auch einsetzen. Eine alternative Umsetzung ausschließlich mit Komponenten der Spezifikation ist möglich, benötigt dann aber aufwändigere Konstrukte im HTML- und CSS-Code und soll hier nicht weiter Gegenstand sein. Auf der Web-Site des Buches steht der Quell-Code für die dargestellten Seiten zur Verfügung. Wir gehen daher im Folgenden nicht auf das Menü, den Seitenkopf und die Fußzeile ein und verweisen für weitere Informationen auf die Web-Site des Buches, von der Sie den kompletten Quell-Code herunterladen können. Listing 3.6: Persönliche Daten als JSF-Code (persoenliche-daten.jsp) 1 <h:form id=" form "> 2 < h: panelgrid columns =" 2" styleclass =" bordertable "

14 3.4 Realisierung 33 3 style =" width: 100%; " headerclass =" panelheading " > 4 < f:facet name =" header "> 5 < h: outputtext value =" Persönliche Daten " / > 6 </ f:facet > 7 < h:outputlabel for =" anrede " value =" Anrede: " /> 8 < h: selectonemenu id =" anrede " 9 value ="#{ persoenlichedatenhandler. kunde. geschlecht " > 10 < f: selectitem itemvalue =" m" itemlabel =" Herr "/ > 11 < f: selectitem itemvalue =" w" itemlabel =" Frau "/ > 12 </ h: selectonemenu > 13 < h: outputlabel for =" vorname " value =" Vorname: " / > 14 < h: inputtext id =" vorname " 15 value ="#{ persoenlichedatenhandler. kunde. vorname " / > 16 < h: outputlabel for =" nachname " value =" Nachname: " / > 17 < h: inputtext id =" nachname " 18 value ="#{ persoenlichedatenhandler. kunde. nachname " / > 19 < h: outputlabel for =" geburtsdatum " value =" Geburtsdatum: " / > 20 < h: inputtext id =" geburtsdatum " 21 value ="#{ persoenlichedatenhandler. kunde. geburtsdatum " > 22 < f:convertdatetime pattern ="dd.mm. yyyy " /> 23 </ h: inputtext > 24 < h: outputlabel for =" strasse " value =" Straße: " / > 25 < h: inputtext id =" strasse " 26 value ="#{ persoenlichedatenhandler. kunde. strasse " / > 27 < h:outputlabel for =" plz " value =" PLZ: " /> 28 < h:inputtext id=" plz " 29 value ="#{ persoenlichedatenhandler. kunde. plz " /> 30 < h:outputlabel for =" ort " value =" Ort: " /> 31 < h:inputtext id=" ort " 32 value ="#{ persoenlichedatenhandler. kunde. ort " /> 33 </ h: panelgrid > 34 < h: panelgrid columns =" 1" > 35 < h: commandbutton value =" Änderungen speichern " 36 action ="#{ persoenlichedatenhandler. save " / > 37 </ h: panelgrid > 38 </ h:form > Listing 3.6 zeigt den JSF-Code für die Verwaltung der persönlichen Daten. Die ersten Tags sind bereits bekannt. Neu ist das Tag <h:selectonemenu> in Zeile 8. Diese Komponente erzeugt eine Drop-down-Liste, die zur Auswahl der Anrede dient. Über eine Wertebindung wird der aktuelle Wert der Auswahl mit dem JSF-EL-Ausdruck #{ persoenlichedatenhandler. kunde. geschlecht verbunden. Wir hatten bereits bei der Anmeldung derartige Ausdrücke verwendet, jedoch in einfacherer Form. Die JSF-Expression-Language ähnelt der

15 34 3 Der Anwendungsprototyp JSP-Expression-Language und wird in Abschnitt 4.2 vorgestellt. Sie enthält Konzepte, wie man sie auch in JavaScript und XPath, einer Sprache zur Referenzierung von Elementen eines XML-Dokuments, findet. Der obige Ausdruck wird auf zwei Arten verwendet, zum Lesen und zum Schreiben. Er entspricht dabei ungefähr den folgenden Code-Fragmenten: PersoenlicheDatenHandler persoenlichedatenhandler ;... // in die HTML - Ausgabe schreibend : <HTML - Code > persoenlichedatenhandler. getkunde (). getgeschlecht () <HTML -Code >... // aus der HTML - Eingabe lesend : persoenlichedatenhandler. getkunde (). setgeschlecht ( < HTML - Eingabe >); Wenn die JSF-Implementierung den HTTP-Request erhält und beginnt, ihn abzuarbeiten, werden die beteiligten JavaBeans über die Setter mit den Werten des HTML-Formulars versorgt. Nach der Abarbeitung der Anwendungslogik wird auf dem Server HTML-Code erzeugt, bei dem die entsprechenden Formularwerte mit den Werten der JavaBeans über die Getter gesetzt werden. Für die <h:inputtext>-tags ist dies leicht vorstellbar, für das <h:select- OneMenu>-Tag muss ein wenig weiter ausgeholt werden. Dem MVC-Pattern liegt eine völlige Trennung zwischen Modell und View zugrunde. Unser Modell des UML-Klassendiagramms aus Abbildung 3.2 beschreibt das Geschlecht als Zeichen, das die Werte m und w für männlich und weiblich annehmen kann. In der View sind mehrere Möglichkeiten vorstellbar, z. B. als Radio- Button oder als Drop-down-Menü. Wir haben uns für die zweite Möglichkeit entschieden, die mittels eines <h:selectonemenu> zu realisieren ist. Es muss nun eine Konvertierung der Anzeige Herr/Frau zu den Modellwerten m/w und umgekehrt erfolgen. Dies wird durch die geschachtelten <f:selectitem>- Tags erreicht. Der Item-Wert wird für die Getter und Setter der JavaBean verwendet, das Item-Label für die Darstellung in HTML. Die restlichen Eingaben sind Texte, so dass diese unproblematisch sind. Einzige Ausnahme ist das Eingabefeld des Geburtsdatums. Das Geburtsdatum ist auf Bean-Seite vom Typ java.util.date. Auf der HTML-Seite kann es aber nur ein String sein. Da die Konvertierung eines Datums oder etwa einer Zahl in einen String und umgekehrt zu den häufigeren Aufgaben bei der Entwicklung von Web-Anwendungen gehört, stellen JavaServer Faces eine Reihe vordefinierter Konvertierer bereit. Im Falle des Geburtsdatums verwenden wir in Zeile 22 den Datum-Konvertierer, der sehr viele Möglichkeiten der Konfiguration kennt. Eine Möglichkeit der Einstellung erfolgt über ein Pattern,

16 3.4 Realisierung 35 das die Struktur des Datums darstellt. Hier wird als Pattern Tag, Monat, vierstelliges Jahr, durch Punkt getrennt definiert. Die Seite wird mit einer Schaltfläche zum Abspeichern eventueller Änderungen abgeschlossen. In Zeile 36 wird im action-attribut die Methode save() als aufzurufende Methode bei Betätigung der Schaltfläche definiert. Die Java- Implementierung der Methode save() innerhalb der Handler-Bean ist trivial und reduziert sich auf einen Methodenaufruf des DAO-Objekts. Den interessierten Leser vertrösten wir für Persistenzfragen auf Abschnitt 6.4. public class PersoenlicheDatenHandler { private Kunde kunde ; public String save () { new DAO (). saveorupdate ( kunde ); return " success "; Überweisungen Der Anwendungsfall Überweisung durchführen muss für unseren Prototypen etwas eingeschränkt werden. Da nur die JSF-Bank existiert und damit kein Zahlungsverkehr zwischen Banken realisiert werden kann, können Überweisungen nur innerhalb der Konten der JSF-Bank getätigt werden. Bei einer Überweisung sind somit die Kontonummer des Empfängerkontos, der Verwendungszweck und der Betrag anzugeben. Abbildung 3.7 auf der nächsten Seite zeigt die fertige Überweisungsseite im Browser. Die Überweisungsseite ist sehr einfach strukturiert. Die eigentliche Durchführung der Überweisung ist allerdings der komplexeste Anwendungsfall des Prototypen. Schauen wir uns zunächst die JSF-Seite im Quell-Code an, der in Listing 3.7 dargestellt ist. Listing 3.7: Überweisungsseite (ueberweisung.jsp) 1 <h:form id=" form "> 2 < h: panelgrid columns =" 1" styleclass =" standardtable " 3 style =" width: 100%; " headerclass =" panelheading " > 4 < f:facet name =" header "> 5 < h: outputtext value =" Überweisung " / > 6 </ f:facet > 7 < h: panelgrid columns =" 2" styleclass =" bordertable " > 8 < h: outputlabel for =" selectonemenukonto " value =" Konto: " / >

17 36 3 Der Anwendungsprototyp Abbildung 3.7: Überweisungen 9 < h: selectonemenu id =" selectonemenukonto " 10 value ="#{ ueberweisunghandler. konto " 11 converter =" KontoConverter " > 12 < f: selectitems value ="#{ kundenhandler. kontenitems " / > 13 </ h: selectonemenu > 14 < h: outputlabel for =" kontonummer " 15 value =" Kontonummer Empfänger: " / > 16 < h: inputtext id =" kontonummer " required =" true " 17 value ="#{ ueberweisunghandler. kontonummer " / > 18 < h: outputlabel for =" verwendungszweck " 19 value =" Verwendungszweck: " / > 20 < h: inputtext id =" verwendungszweck " required =" true " 21 value ="#{ ueberweisunghandler. verwendungszweck " / > 22 < h:outputlabel for =" betrag " value =" Betrag " /> 23 < h:inputtext id=" betrag " required =" true " 24 value ="#{ ueberweisunghandler. betrag "> 25 < f: validatedoublerange minimum =" 1" maximum =" 1000 " / > 26 </ h: inputtext > 27 </ h: panelgrid > 28 < h: commandbutton id =" ueberweisen " 29 value =" Überweisung durchführen " 30 action ="#{ ueberweisunghandler. ueberweisen " / > 31 </ h: panelgrid > 32 </ h:form > Die ersten Zeilen sind als Wiederholung bereits bekannt. Interessant wird es in den Zeilen 9 bis 13. Hier wird wieder ein <h:selectonemenu>-tag verwen-

18 3.4 Realisierung 37 det, um in der Drop-down-Auswahl eine Liste aller Konten des Kunden zu erzeugen. Während im letzten Beispiel die Unterscheidung der Anrede in Herr und Frau statisch gewesen ist, sind die Konten nicht vorherbestimmt und unterscheiden sich von Kunde zu Kunde. Die Konten müssen daher aus dem Business-Modell bzw. aus der Datenbank geholt und dynamisch für die Darstellung in der Drop-down-Auswahl vorbereitet werden. Um dies zu erreichen, müssen prinzipiell zwei Funktionalitäten realisiert werden: zum einen die Möglichkeit, eine dynamische Liste zu erstellen, zum anderen, Modell-Objekte in Strings (die Anzeige) und Strings in Modell-Objekte konvertieren zu können. Die erste Funktionalität wird durch das <f:selectitems>-tag realisiert, das als value-attribut eine Liste von Objekten des Typs javax.faces.model.selectitem erwartet. Die zweite Funktionalität, die Konvertierung von Modell- Objekten, wird durch einen anwendungsspezifischen Konvertierer realisiert. In Zeile 11 wird der Konvertierer KontoConverter dem Attribut converter zugewiesen. Die weiteren Komponenten der Seite sind bereits bekannt, so dass wir uns der SelectItem-Liste und dem Konvertierer widmen. Die Methode getkontenitems() des Kunden-Handlers liefert die entsprechenden SelectItems. Die Implementierung der Methode ist in Listing 3.8 dargestellt. Listing 3.8: Die Managed-Bean KundenHandler public List getkontenitems () { if ( this. kontenitems == null ) { List kontenitems = new ArrayList (); for ( Iterator i = konten. iterator (); i. hasnext ();) { Konto tmp = ( Konto ) i. next (); kontenitems. add ( new SelectItem ( tmp, KontoConverter. getasstring ( tmp ))); this. kontenitems = kontenitems ; return this. kontenitems ; Die Methode getkontenitems() wird über das <f:selectitems>-tag immer aufgerufen, wenn die Seite neu darzustellen ist. Ein Kunde kann zwar eines seiner Konten kündigen oder ein neues Konto zu den bereits bestehenden hinzubekommen, doch kommt dies während einer Online-Banking-Sitzung relativ selten vor. Der Kunden-Handler merkt sich daher in der Instanzvariablen kontenitems die Liste der Konten als SelectItems. Die Variable wird nach

19 38 3 Der Anwendungsprototyp dem Lazy-Initializer-Pattern erst bei Bedarf, d. h. bei der ersten Verwendung initialisiert, danach bei jedem weiterem Zugriff ohne neuen Berechnungsvorgang zurückgegeben. Die Instanzvariable konten ist die Liste der Konten des Kunden. Der Konstruktor von javax.faces.model.selectitem ist überladen. In der von uns verwendeten Version SelectItem ( java. lang. Object value, java. lang. String label ) wird im ersten Parameter das Objekt selbst, im zweiten Parameter der anzuzeigende String übergeben. Das JSF-Laufzeitsystem erzeugt aus der SelectItem- Liste eine Liste von Strings, die in der Drop-down-Liste zur Anzeige gebracht werden. Umgekehrt muss bei einer Anfrage aus dem selektierten String wieder ein Konto-Objekt erzeugt werden. Hierzu wird ein Konvertierer benötigt. Für alle Standardtypen gibt es entsprechende Konvertierer, für ein Konto muss ein Konvertierer erstellt werden. Das Listing 3.9 zeigt Teile der Konvertiererklasse KontoConverter, die die Konvertierung zwischen Konten und Strings realisiert. Listing 3.9: Der Konvertierer KontoConverter public class KontoConverter implements Converter { public Object getasobject ( FacesContext context, UIComponent component, String value ) throws ConverterException {... public String getasstring ( FacesContext context, UIComponent component, Object value ) throws ConverterException {... public static String getasstring ( Konto konto ) { return konto. tostring (); Ein Konvertierer muss das Interface javax.faces.convert.converter implementieren, das aus den beiden Methoden getasobject() und getasstring()

20 3.4 Realisierung 39 besteht, die einen String in ein Objekt bzw. ein Objekt in einen String konvertieren. Die Implementierung ist durch die Persistenz von Konten nicht trivial, so dass wir an dieser Stelle auf eine detaillierte Darstellung verzichten. Der letzte erwähnenswerte Punkt bei der Überweisungsseite ist die Eingabe und Anzeige des Überweisungsbetrages. Das InputText-Tag ist an die Bean- Property betrag gebunden (Zeile 23). Diese ist vom Typ BigDecimal. Java- Server Faces erkennt den Kompatibilitätskonflikt zwischen String und Big- Decimal und setzt automatisch einen der Standard-Konvertierer ein. Dieser Konvertierer geht im Default-Falle von einer amerikanischen Zahlendarstellung aus, so dass ein Dezimalpunkt statt des im Deutschen üblichen Dezimalkommas verwendet wird. Für den Prototypen ist dieses Verhalten noch zu verzeihen, in der endgültigen Anwendung werden wir dieses Manko beheben. Der in der Überweisungsseite verwendete Handler UeberweisungHandler ist in Listing 3.10 dargestellt. Der Überweisungs-Handler besteht zum größten Teil aus der Methode ueberweisen(). Der Rest sind die Properties mit Gettern und Settern. Wir verzichten auf eine Komplettdarstellung des Handlers. Listing 3.10: Methode ueberweisen() der Klasse UeberweisungHandler public String ueberweisen () { try { Konto ziel = new KontoDAO (). getkontobyid ( kontonummer ); Transaktionslog t1 = new Transaktionslog (); t1. setart ( E ); t1. setbetrag ( betrag ); t1. settext ( verwendungszweck ); t1. setdatum ( new Date ()); ziel. addtransaktion (t1 ); ziel. setkontostand ( ziel. getkontostand (). add ( betrag )); Transaktionslog t2 = new Transaktionslog (); t2. setart ( A ); t2. setbetrag ( betrag ); t2. settext ( verwendungszweck ); t2. setdatum ( new Date ()); konto. addtransaktion (t2 ); konto. setkontostand ( konto. getkontostand (). subtract ( betrag )); new DAO (). saveorupdate ( ziel ); new DAO (). saveorupdate ( konto ); return " success "; catch ( ObjectNotFoundException e) { return " unbekanntes Konto ";

21 40 3 Der Anwendungsprototyp Beim Aufruf dieser Methode stehen in den Instanzvariablen kontonummer, betrag und verwendungszweck die Eingaben der Seite. Der Java-geübte Leser wird die Methode problemlos verstehen können. Im Transaktionslog wird zwischen Ein- und Auszahlungen durch die Art-Angaben E und A unterschieden. Das als OR-Mapper verwendete Hibernate wirft eine ObjectNotFound- Exception, falls das Konto des Empfängers nicht existiert. Ganz analog zur Navigationsregel in Listing 3.3 auf Seite 28 erfolgt hier die Anzeige einer Fehlermeldung. Wir verzichten daher auf die Darstellung der Navigationsregel und der JSF-Seite für die Fehlermeldung Kontenübersicht Als Kunde der JSF-Bank wird man in der Regel mehrere Konten besitzen, z. B. ein Giro-, ein Spar- und ein Festgeldkonto. Unser Business-Modell in Abbildung 3.2 auf Seite 24 sieht Giro- und Sparkonten vor. Der Anwendungsfall Anzeige der Kurzinformationen zu allen Konten ist recht einfach und besteht aus der Anzeige der Kontoart, der Kontonummer und des aktuellen Kontostands. Abbildung 3.8 zeigt die Darstellung im Browser. Abbildung 3.8: Kontenübersicht Anwendungen besitzen häufig eine Anzeigemöglichkeit für a priori unbekannt viele Datensätze. Bei der Kontenübersicht kann ein Kunde ein Konto, ein anderer Kunde 20 Konten besitzen. JavaServer Faces besitzen das <h:datatable>- Tag, mit dem die spaltenweise Darstellung beliebig vieler Zeilen möglich ist.

22 3.4 Realisierung 41 Listing 3.11 zeigt die Datentabelle der Kontenübersicht-Seite. Auf die Anzeige der Kundendaten oberhalb der Kontenübersicht verzichten wir. Listing 3.11: Datentabelle der Kontenübersicht 1 < h:datatable id=" data " style =" width: 100% " 2 styleclass =" standardtable " 3 headerclass =" standardtable_ Header " 4 rowclasses =" standardtable_ Row1, standardtable_ Row2 " 5 columnclasses =" standardtable_ ColumnCentered " 6 var =" konto " value ="#{ kundenhandler. konten "> 7 < h:column > 8 < f:facet name =" header "> 9 < h: outputtext value =" Kontoart " / > 10 </ f:facet > 11 < h:outputtext value ="#{ konto. class. simplename " /> 12 </ h:column > 13 < h:column > 14 < f:facet name =" header "> 15 < h: outputtext value =" Kontonummer " / > 16 </ f:facet > 17 < h:outputtext value ="#{ konto.id" /> 18 </ h:column > 19 < h:column > 20 < f:facet name =" header "> 21 < h: outputtext value =" Kontostand " / > 22 </ f:facet > 23 < h:outputtext value ="#{ konto. kontostand " /> 24 </ h:column > 25 </ h: datatable > Das <h:datatable>-tag besitzt zwei Attribute, die für die Iteration über die Daten benötigt werden. Das Attribut value (im Listing in Zeile 6) ist eine Wertebindung, die eine Referenz auf ein List-Objekt oder ein Array liefern muss. Möglich sind auch JDBC-ResultSets, JSTL-ResultSets und andere Objekte. Das Attribut var (ebenfalls Zeile 6) deklariert einen Bezeichner, der analog zu einem Iterator des Collection-Frameworks über die Daten iteriert. Dieser Iterator wird innerhalb der Spalten wiederum in Wertebindungen über Getter zugegriffen. Die Tabelle der Kontenübersicht besteht aus drei Spalten (<h:column>-tag) mit den Überschriften (<f:facet>-tag mit Attribut name="header") Kontoart, Kontonummer und Kontostand. Der Zeilenwert einer jeden Spalte wird durch das <h:outputtext>-tag belegt. In der Spalte Kontoart ist dies konto.class.simplename, ein JSF-EL-Ausdruck, der dem Java-Ausdruck konto.getclass().getsimplename() entspricht. Die Metho-

23 42 3 Der Anwendungsprototyp de Class.getSimpleName() gibt den Namen der Klasse ohne Package-Präfix zurück. Die Methode wurde in Java 5.0 dem Class-API hinzugefügt. Die Spalte Kontonummer enthält die Id eines Kontos. Dieses Attribut ist im UML- Klassendiagramm in Abbildung 3.2 nicht enthalten, da es als Implementierungsdetail des OR-Mappers in alle Java-Klassen aufgenommen werden muss, die persistent gemacht werden sollen und nicht zur Fachlichkeit gehört. Das Attribut entspricht dem Primärschlüssel der Datenbank. Die Spalte Kontostand enthält schließlich den Wert des Properties kontostand. Der komplette Quell-Code der Seite ist über die Web-Site des Buches zu erhalten Umsatzanzeige Der letzte Anwendungsfall ist die Anzeige der Umsätze. Für ein auszuwählendes Konto werden die Umsätze tabellarisch angezeigt. Im Prototyp werden alle Umsätze angezeigt, die produktive Anwendung wird Möglichkeiten zur Selektion von Umsätzen anbieten. Abbildung 3.9 zeigt die Darstellung im Browser. Die Seite enthält auf den ersten Blick nur bekannte Elemente: eine Drop-down- Auswahl, eine Schaltfläche und eine Tabelle. Trotzdem lohnt ein Blick in den Quell-Code. Listing 3.12 zeigt den interessanten Teil der JSF-Seite. Abbildung 3.9: Umsatzanzeige

24 3.4 Realisierung 43 Listing 3.12: Ausschnitt der JSF-Seite Umsatzanzeige 1 < h: panelgrid columns =" 3" styleclass =" bordertable " 2 style =" width: 100%; " > 3 < h: outputtext value =" Konto: " / > 4 < h: selectonemenu id =" selectonemenukonto " 5 value ="#{ umsatzanzeigehandler. konto " 6 converter =" KontoConverter " > 7 < f: selectitems value ="#{ kundenhandler. kontenitems " / > 8 </ h: selectonemenu > 9 < h: commandbutton value =" Aktualisieren " 10 action ="#{ umsatzanzeigehandler. aktualisieren "/ > 11 </ h: panelgrid > 12 < h: datatable id =" data " style =" width: 100%; " 13 styleclass =" standardtable " 14 headerclass =" standardtable_ Header " 15 rowclasses =" standardtable_ Row1, standardtable_ Row2 " 16 columnclasses =" standardtable_ Column " 17 var =" transaktion " 18 value ="#{ umsatzanzeigehandler. transaktionen " > 19 < h:column > 20 < f:facet name =" header "> 21 < h: outputtext value =" Buchungsdatum " / > 22 </ f:facet > 23 < h:outputtext value ="#{ transaktion. datum "> 24 < f:convertdatetime pattern ="dd.mm. yyyy " /> 25 </ h: outputtext > 26 </ h:column > Das <h:selectonemenu>-tag in den Zeilen 3 bis 7 zeigt alle Konten des Kunden an und ist identisch mit der Überweisungs-Seite (Listing 3.7 auf Seite 36) mit Ausnahme des value-attributs. Dies wird hier an das Property konto des Umsatzanzeige-Handlers gebunden. Die in Zeile 11 beginnende Datentabelle ist ähnlich der Datentabelle der Kontenübersicht aufgebaut. Interessant ist hier das Property transaktionen des Umsatzanzeige-Handlers. Wir schauen uns dieses Property nun genauer an. Listing 3.13 zeigt einen Ausschnitt der Klasse UmsatzanzeigeHandler. Listing 3.13: Ausschnitt der Klasse UmsatzanzeigeHandler public class UmsatzanzeigeHandler { private Konto konto ; // Konto des SelectOneMenu public List gettransaktionen () { if ( konto!= null ) {

25 44 3 Der Anwendungsprototyp new DAO (). saveorupdate ( konto ); // an Session binden return new ArrayList ( konto. gettransaktionen ()); return null ; public String aktualisieren () { return " success ";... Die Methode gettransaktionen(), die in der JSF-Seite als Datenquelle verwendet wird, gibt die Liste aller Transaktionslog-Einträge des ausgewählten Kontos zurück. Zunächst wird die Variable konto wieder mit der aktuellen Hibernate-Session verbunden, da das konto-objekt zum Zeitpunkt des Methodenaufrufs mit keiner Session verbunden ist. Eine ausführliche Darstellung und Begründung des Vorgehens erfolgt in Abschnitt 6.4. Im Augenblick konzentrieren wir uns auf die Fertigstellung unseres Prototyps. Die Methode gettransaktionen() der Klasse Konto gibt ein java.util.set zurück, die Methode verlangt aber einen Rückgabewert vom Typ List. Dies lässt sich am einfachsten durch einen Wrapper der Klasse ArrayList realisieren. Die als Action-Methode der Schaltfläche verwendete Methode aktualisieren() besteht lediglich aus der Rückgabe der Konstanten "success". Welche Funktion wird durch diese Methode erfüllt? Wählt der Benutzer in der Dropdown-Liste ein Konto aus und betätigt die Schaltfläche, so wird vor Aufruf der Methode aktualisieren() das in der Drop-down-Liste aktuell selektierte Konto der Variablen konto zugewiesen. Zur neuen Darstellung der Datentabelle wird die Methode gettransaktionen() aufgerufen, und zwar für das neu ausgewählte Konto. Damit ist die Methode aktualisieren() nur eine Placebo-Methode ohne eigentliche Aufgabe. Die explizite Betätigung der Schaltfläche nach der Auswahl eines Kontos ist nicht sehr benutzerfreundlich und im Prinzip unnötig. Wir werden dieses Manko in Kapitel 6 beseitigen. In diesem Kapitel haben wir den Prototypen unseres Online-Bankings erstellt. Die typische Struktur einer JSF-basierten Anwendung wurde vorgestellt, und wir haben einige Details einer solchen Anwendung auch realisiert. Viele Fragen bleiben allerdings auch offen. Im folgenden Kapitel wird die Struktur und Funktionsweise einer JSF-Implementierung ausführlich dargestellt, um diese Fragen zu beantworten.

26 3.4 Realisierung 45 Aufgabe 3.1 Der JSF-EL-Ausdruck "#{umsatzanzeigehandler.aktualisieren" gibt die Konstante "success" zurück, die allerdings in keiner Navigationsregel verwendet wird. Die Konstante selbst ist ebenfalls ein Ausdruck und kann auch direkt verwendet werden. Ändern Sie die JSF-Seite so ab, dass als Wert des action-attributs der Schaltfläche die String-Konstante steht, und überzeugen Sie sich von der korrekten Funktion.