Ausarbeitung Web Frameworks

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Web Frameworks im Rahmen des Seminars Softwaretechnik Jan Ackermann Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl.-Wirt.Inform. Christoph Lembeck Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Grundlagen Framework für Web Applikationen Model-View-Controller Jakarta Struts Model 2 Architektur MVC in Struts Struts Controller Struts Model Struts View Validierung in Struts Tiles-Layoutmanagement JavaServer Faces MVC in Faces Der Lebenszyklus der Anfrageverarbeitung JSF Tags View Managed Beans Validierung in Faces Konvertierung Eventhandling Navigation Lokalisierung Fazit Literaturverzeichnis II

3 Kapitel 1: Einleitung 1 Einleitung In den letzen Jahren hat sich Java als eine führende Technologie für die Web Application- Development etabliert. Entwickler benutzen Technologien wie Servlets und JavaServer Pages, um skalierbare und robuste browserbasierte Anwenderschnittstellen für zahllose Anwendungen mit großem Erfolg zu entwickeln. Aber immer komplexer werdende Webanwendungen machten es notwendig, im Sinne der Wartbarkeit, Wiederverwendbarkeit, Erweiterbarkeit, Konfigurierbarkeit und einfacher Entwicklung sich grundsätzliche Gedanken über die Struktur von Webanwendungen zu machen. Die Zeiten, in denen Java Entwickler eine einzige JSP- Seite hatten, die sowohl Präsentationslogik, Geschäftslogik und Navigationslogik enthielt, sind mit der Nutzung dieser Web-Frameworks vorbei. Die Entwicklung von zahlreichen Web- Frameworks in der Umgebung von Java und J2EE unterstützt diese Annahme. Laut Entwickler des Struts Web-Frameworks Craig McClanahan ist diese aus jener Notwendigkeit heraus entstanden. In dieser Seminararbeit soll die Funktionsweise der Web-Frameworks Jakarta Struts und JavaServer Faces vorgestellt werden. Das Open Source Framework Struts wurde von Craig McClanahan entwickelt und im Jahr 2000 der Apache Software Foundation zur Verfügung gestellt. Schnell wurde dieses inzwischen sehr häufig genutzte und beliebte Web-Framework zu einem Apache-Top-Level- Projekt. Craig McClanahan konnte nach Fertigstellung des Frameworks von Sun für JavaServer Faces als Specification Lean angeworben werden und ist nun maßgeblich neben Ed Burns an der Entwicklung von JavaServer Faces beteiligt. In dieser Arbeit wird in Kapitel 2.1 der Begriff Framework erläutert, um ein grundlegendes Verständnis für die Struktur von Frameworks zu erhalten. In dem Kapitel 2.2 wird das Architekturmuster vorgestellt, welches als konzeptionelle Struktur diesen und fast allen Web- Framewoks im Umfeld von Java zugrunde liegt. Auf dieser Grundlage werden die beiden Web-Frameworks vorgestellt, um die Gemeinsamkeiten und Unterschiede aufzuzeigen. Begonnen wurde mit dem Framework Struts, um dann im zweiten Teil anhand von JavaServer Faces einige Bestandteile vergleichend zu erläutern. 3

4 Kapitel 2: Grundlagen 2 Grundlagen 2.1 Framework für Web Applikationen Ein Framework besteht aus einer Menge kooperierender Klassen, die ein wiederverwendbares Design für einen bestimmten Anwendungsbereich darstellen. Durch ein Framework wird die Architektur der Anwendung festgelegt. Das Framework definiert die Struktur im Großen, seine Unterteilung in Klassen und Objekte, die jeweiligen zentralen Zuständigkeiten, die Zusammenarbeit der Klassen und Objekte sowie den Kontrollfluss [GHJV96 S.37]. Ein Framework dient dem Anwendungsprogrammierer, der sich auf die Entwicklung der spezifischen Anwendung konzentrieren kann um einen Geschäftswert zu liefern; denn die Entwurfsentscheidungen und Technik, die er nutzt, sind in dem Framework im Voraus festgelegt. Die in einem Framework enthaltenen Entwurfsentscheidungen sind dabei in ihrem Anwendungsbereich allgemein anzutreffen. Frameworks betonen die Entwurfswiederverwendung gegenüber der Codewiederverwendung von z.b. Klassen-Bibliotheken, obwohl ein Framework üblicherweise konkrete Unterklassen enthält, die sofort verwendet werden können. Bei der Verwendung von Bibliotheken schreibt man die ausführende Anwendung selbst und nutzt die Funktionalitäten der Bibliotheken. Mit dem Verwenden eines Frameworks wird der frameworkspezifische Code zur Ausführung genutzt und mit anwendungsspezifischem Code erweitert. Für die Erweiterung stehen verschiedene Techniken zur Verfügung, die durch das Framework selbst festgelegt werden, wie zum Beispiel die Programmierung von Unterklassen der abstrakten Frameworkklassen des Frameworks. Dieser Code enthält dann wieder Operationen und Aufrufkonventionen des Frameworks. Das Framework übernimmt also die globale Steuerung und es werden Entwurfsentscheidungen des Programmierers massiv reduziert [GHJV96 S.37]. Mit einem Framework können Anwendungen schneller entwickelt werden und aufgrund ähnlicher Strukturen sind diese einfacher zu warten und konsistenter. Man verliert allerdings einige kreative Freiheit, da viele Entwurfsentscheidungen bereits für den Entwickler getroffen wurden. Ein Frameworkentwurf ist ein komplexer Softwareentwurf, der für alle Anwendungen eines Anwendungsbereichs (z.b. Web-Applikationen) funktionieren soll. Der Entwurf stützt sich häufig auf ein komplexes System von zusammenspielenden Entwurfsmustern, um seine Anwendung robust zu machen. Jede substantielle Änderung am Framework würde seine Vorteile deutlich reduzieren, da der Hauptbeitrag eines Frameworks zu einer Anwendung in der von ihr definierten Architektur liegt. Deswegen sollte ein Framework so flexibel und erweiterbar wie möglich entworfen werden. Laut [GHJV96] gewinnen Frameworks an Bedeutung, denn mit ihrer Hilfe erreichen objektorientierte Systeme den höchsten Grad an Wiederverwendung. 4

5 Kapitel 2: Grundlagen Die hier vorgestellten Frameworks fallen in den Anwendungsbereich der Java-basierten Frameworks für Web-Applikationen, und ihre konzeptionelle Struktur folgt dem Ansatz des Model-View-Controller Architekturmusters. Sie nutzen Technologien wie JavaServer Pages und Java Servlets. Sie arbeiten im technischen Umfeld des web-typischen Request/Response- Zyklus des HTTP-Protokolls und werden häufig im J2EE Bereich eingesetzt. Dabei lassen sich die entwickelten Web Frameworks vielfach einem der folgenden Typen zuordnen [CS03]: Ereignisgesteuerte Web-Frameworks folgen dem ereignisgesteuerten Programmiermodel. In einer ereignisorientierten Umgebung definiert der Programmierer für spezielle Komponenten vorab die Reaktion auf ein bestimmtes Ereignis, welche dann zur Laufzeit durch Benutzeraktion mit der Komponente ausgelöst werden kann. Für jede Komponente kann dabei eine individuelle Reaktion auf ein Ereignis implementiert werde. Eine Stärke des ereignisorientierten Models besteht darin, dass der Vorteil der objektorientierten Programmierung, der Kapselung von Objekten mit Zustand und Verhalten, auf die Programmierung von Oberflächen übertragen werden kann. Einige Frameworks weisen konzeptionelle Analogien zur ereignisgesteuerten Swing-Technologie auf. Aktionsgesteuerte Web-Frameworks orientieren sich stärker an den technischen Besonderheiten des HTTP-Protokolls und definieren ihre Anwendungssteuerung entlang des webtypischen Request/Response-Zyklus. Konzeptionell lehnen sich diese Web-Frameworks stark an eine Variante des Model-View-Controller Musters, die Sun Model 2 Architektur an. Eintreffende Requests werden auf Actions abgebildet, die global definiert werden. Der Request wird immer als ganzes verstanden, eine Aufteilung in Komponenten und davon ausgehende Ereignisse gibt es nicht. 2.2 Model-View-Controller Den in der Seminararbeit vorgestellten Web-Frameworks liegt konzeptionell das Model- View-Controller Architekturmuster zugrunde. Architekturmuster beschreiben den Aufbau, also die Struktur eines Softwaresystems, unterteilen das System in Subsysteme und spezifizieren deren Zuständigkeitsbereich. Das Model-View-Controller Architekturmuster, kurz MVC, fand ihre erstmalige Ausprägung in der Programmiersprache Smalltalk-80 zur Konstruktion von Benutzerschnittstellen [KP88]. Das MVC-Paradigma teilt die Zuständigkeiten in drei Komponenten auf und entkoppelt sie, um die Flexibilität und Wiederverwendbarkeit zu erhöhen [GHJV96 S.5 ff]. Das Model kapselt die Daten und ist unabhängig von einer bestimmten Darstellung der Ausgabe oder einem bestimmten Verhalten der Eingabe. Von ihr abhängige Sichten und Kontrollen werden registriert und bei Datenänderung benachrichtigt. Das Model repräsentiert den 5

6 Kapitel 2: Grundlagen aktuellen Zustand. Die View ist die Bildschirmrepräsentation einer Modelkomponente. Pro Model kann es mehrere Sichten geben. Eine Sicht liest Daten aus dem Model aus und stellt diese in der gewünschten Form dar. Die View- und Model-Komponenten werden durch den Aufbau eines Protokolls zur Benachrichtigung entkoppelt. Bei Benachrichtigung durch das Model besitzt jede Sicht die Möglichkeit, ihre Darstellung durch Update in einen konsistenten Zustand zu bringen. Abb. : Model-View-Controller Der Controller bestimmt das Verhalten, mit der auf Benutzereingaben durch eine Benutzungsschnittstelle reagiert wird. Er ruft definierte Dienste der zugeordneten Sicht oder des Models auf. Dabei ist jeder Controller genau einer Sicht zugeordnet und mehrere Controller einem Model. Zu Verdeutlichung des dynamischen Verhaltens und des Zusammenspiels der Objekte wird hier ein beispielhafter Durchlauf gezeigt. Ein Controller erhält eine Eingabe (handleevent) und ändert das Model (service). Das Model benachrichtigt (update) die registrierten Beobachter. Jeder Beobachter erfragt daraufhin vom Model den aktuellen Zustand (getdata) und bringt sich selbst auf den neuesten Stand (display). Die Trennung in drei Komponenten bringt bei Java-basierten Web-Frameworks den Vorteil der Arbeitsteilung mit technologiespezifischen Arbeitsfeldern. Page Autoren erstellen Webseiten (View) und besitzen Fähigkeiten im Bereich Javascript, JavaServer Pages und HTML. Application Developer sind für die Speicherung der Daten und die Kapselung der Geschäftslogik verantwortlich. Sie entwerfen Schnittstellen zu den Modelkomponenten. Ihre Fähigkeiten liegen im Bereich der Anwendungsprogrammierung. Zudem kann man noch die Rolle des Component Writer unterscheiden, dessen Fähigkeiten in dem Framework selbst liegen. Seine Aufgabe besteht in der anwendungsspezifischen Erweiterung des Frameworks mit wiederverwendbaren Komponenten. 6

7 Kapitel 3: Jakarta Struts 3 Jakarta Struts Struts ist ein aktionsgesteuertes Open Source Web-Framework der Apache Software Foundation. Es stützt sich mitunter auf die Java Technologien Java Servlets und JavaServer Pages der Java 2 Platform Enterprise Edition (J2EE). Um die Funktionsweise von Struts aufzuzeigen, werden der Anfrageverarbeitungszyklus und die Komponenten von Struts anhand des MVC erläutert. Abschließend werden die Validierung und das Layoutmanagement beschrieben. 3.1 Model 2 Architektur MVC in Struts Unter dem Namen Model 2 Architektur ist von Sun ein Architekturvorschlag des Model- View-Controller Paradigmas vorgestellt worden, welches im Rahmen der Servlet-Technologie eine geeignete Umsetzung darstellt und in Struts umgesetzt ist. Model 2 Architektur von Sun Die Elemente der Model 2 Architektur und der Request-Response-Zyklus werden in der Abbildung dargestellt. Ein Client-Browser sendet eine Anfrage (post) an den Controller (Action- Servlet). Die Controller-Komponente definiert die Abbildung von Anfragen auf bestimmte Actions (ActionMapping). Das Controller-Servlet schickt die Anfrage an diese bestimmte Actionklasse, in der die Ausführung der Action stattfindet. Hier werden die Benutzereingaben ausgelesen, Geschäftslogik ausgeführt und die nächste View wird vorbereitet, indem die von der View benötigten Modelelemente (JavaBeans) mit Daten gefüllt werden. In dem Controller bestimmen Navigationsregeln welche View (JavaServer Page) als nächstes angezeigt werden soll. Dazu benötigt das ActionServlet einen Rückgabewert (Forward) von der Action, der über den nächsten Navigationsfall entscheidet. Die Action sendet also in Abhängigkeit von der Ausführung einen Rückgabewert, der die nächste View bestimmt. Das Action-Servlet ruft die 7

8 Kapitel 3: Jakarta Struts so bestimmte View auf, welche dann die Daten aus dem aktualisierten Model ausliest. Danach wird die View als Antwort zurückgegeben. 3.2 Struts Controller Die Controller-Komponente in der Model 2 Architektur wird durch ein Java Servlet realisiert, eine Instanz der Klasse Action-Servlet. Als Java Servlet bezeichnet man im Rahmen der Java 2 Plattform Enterprise Edition (J2EE) von Sun Microsystems ein Java-Objekt, an das ein Webserver Requests seiner Clients delegiert [HB04 Kapitel 2]. Bei der ersten Anfrage an ein Java Servlet wird ein Session-Objekt erzeugt, in dessen Kontext die Requests verarbeitet werden. Das Servlet übernimmt also die Ablaufsteuerung des Web-Frameworks pro Client. Nach der Verarbeitung des Request wird vom Servlet eine Antwort (Response) generiert. Die Antwort besteht bei Struts aus einer JavaServer Page. Ein JavaServlet wird im Deployment Descriptor (web.xml) eingebunden. Für Anfragen, die an das Servlet weitergeleitet werden sollen, wird hier ein URL-Pattern festgelegt, sowie die Servlet-Klasse und die Konfigurationsdatei struts-config eingebunden. Die Ablaufsteuerung des Servlets, und damit das Verhalten der Web-Anwendung, wird nicht fest im Quellcode codiert, sondern in der konfigurierbaren XML-Datei struts-config definiert. Die Ausführung einer Action wird definiert durch die Abbildung von URLs auf seine Action-Klassen (Action-Mapping). Die so definierten Actions sind genau für die Verarbeitung eines bestimmten Benutzerereignisses (Request mit Action URL) ausgelegt. Actions werden durch Action-Klassen repräsentiert, die von der Klasse action abgeleitet werden und die Methode execute überschreiben müssen. Soll eine Action ausgeführt werden, so wird die Methode execute der Action vom Controller ausgeführt. <action path="/login" name="loginform" scope="session" input="/login.jsp" validate="false" type="de.actions.login" parameter="method"> <forward name="showview" path="/loginsuccess.jsp"/> <forward name="doaction" path="/myaction.do?method=loginsuccess"/> </action> Die Konfigurationsdatei struts-config.xml ist das zentrale Konstrukt des Controllers, in der das Verhalten der Web-Anwendung durch Actiondefinitionen und Definition der Navigationsmöglichkeiten festgelegt werden. Innerhalb des Action-Mapping-Elements werden beliebig viele dieser Actions eingebunden. Das Codebeispiel zeigt, wie die Abbildung von Action URLs auf Action Klassen erfolgt. Das Actionpath-Attribut gibt die URL des Requests an, auf das das Mapping reagiert. Das Actiontype-Attribut gibt die Implementierungsklasse für die aufzurufende Action an. Unter dem Actionname-Attribut bindet man die FormBean (siehe Model) ein, auf der in der Actionklasse zugegriffen werden soll. Jede Action-Klasse, die innerhalb des Action-Mappings registriert wurde, steht dem Action Servlet zur Verfügung und 8

9 Kapitel 3: Jakarta Struts kann ausgeführt werden. Bei der Navigation stehen dem Action Servlet alle Forwards der Action und global definierte Forwards zu Verfügung. Ein Forward kann dabei auf eine JSP- Seite oder wiederum auf eine Action verweisen. Auf diese Weise kann eine Reihe von Actions hintereinander ausgeführt werden. Ein Forward ist vom Typ String, der unter dem Attribut Forwardname festgelegt wird. public class ExpertlistAction extends org.apache.struts.actions.action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { } String forward = "showview"; //if no errors the forward will set on success LoginForm loginform = (LoginForm) form; //Die hier während der Validierung gesammelten Fehler können in der View an entsprechender Stelle ausgegeben werden. ActionErrors errors = new ActionErrors(); //An dieser Stelle wird beliebiger Code ausgeführt. //Rückgabewert ist ein definierter Forward return mapping.findforward(forward); } In der Action-Klasse wird die Geschäftslogik innerhalb der execute-methode ausgeführt. Der execute-methode wird mitunter auch die ActionForm übergeben, welche durch eine Form- Bean repräsentiert wird und die Daten der View enthält. Registriert wurde die entsprechende FormBean der Action in der struts-config. Die Daten können nun ausgelesen werden, und entsprechende Geschäftslogik wird ausgeführt. Struts bietet keine Unterstützung, wie die Ausführung der Geschäftslogik zu implementieren ist. Zu empfehlen ist an dieser Stelle eine saubere Kapselung der Datenzugriffe und Geschäftslogik. Diese kann durch DAO s [BG04] oder im Zusammenhang mit J2EE durch ein Command Entwurfsmuster [ACM01] gewährleistet werden. Der Vorteil ist darin zu sehen, dass die Actionklassen übersichtlich bleiben und das Framework schlank bleibt. Weiterhin wird hierdurch eine saubere Schnittstelle zur Anwendung an sich geschaffen, und die Struktur der zugrunde liegenden Applikation kann sich ändern, ohne dass das Framework angepasst werden muss. Um Daten der Anwendung in der View anzeigen zu können, muss das Model des Frameworks aktualisiert werden. Die Model-Komponente wird durch Beans repräsentiert, auf die in der View zugegriffen werden kann. Dazu stellt Struts spezielle Tag-Libraries zur Verfügung. 9

10 Kapitel 3: Jakarta Struts Über diese Tags wird dann in der View auf die Model-Komponente zugegriffen. Innerhalb der Action-Methode müssen diese Daten aktualisiert werden. Auf Grundlage des Ergebnisses der Verarbeitung wird in der Action-Klasse die Weiterleitung durch einen String-Return (mapping.findforward) entschieden. Die Weiterleitung kann dabei an ein Global-Forward oder an ein in dem Action-Mapping definierten Forward gerichtet sein. 3.3 Struts Model Der Zugriff im Framework auf die Daten des Models erfolgt über JavaBeans und eine spezielle Form der JavaBean im Struts-Framework, der FormBean. JavaBeans sind ein Komponentenmodel der Firma Sun. Eine JavaBean ist im Wesentlichen eine beliebige Java-Klasse, die den in der JavaBeans-Spezifikation beschriebenen Regeln folgt [HA96]. Eine JavaBean besteht aus bindenden Vereinbarungen, die jeder Programmierer einhalten muß, um eine Java- Bean zu programmieren und auch veröffentlichen zu können. JavaBeans besitzen als definierte öffentliche Schnittstelle eine Menge privater Eigenschaften (Properties), die über öffentliche get() und set()- Methoden manipuliert bzw. ausgelesen werden können. Zudem können sie noch beliebige Methoden besitzen die den Zustand der JavaBean beeinflussen. Innerhalb der JavaBeans werden die Daten nicht gespeichert, sie dienen lediglich dem Transport. Die Speicherung erfolgt innerhalb der Geschäftslogik. Eine FormBean in der Struts-Terminologie ist eine JavaBean, deren Properties mit den UI- Komponenten eines HTML-Formulares korrespondieren. Zur Implementierung einer Form- Bean erweitert man die Klasse ActionForm. Bei einer HTML Anfrage sorgt das Struts Framework nun dafür, dass die von Benutzer eingegebenen Daten aus dem HTML-Formular in der FormBean gespeichert werden. Die FormBean repräsentiert also den serverseitigen Status des HTML Formulares. Nun ist es möglich, die Daten, die nun in Java-Code vorliegen, zu validieren, auszulesen, zu manipulieren oder zu löschen. Der Zugriff innerhalb der View erfolgt über spezielle Struts-Tags in den JavaServer Pages. <form-beans> <form-bean name="loginform" type="de.forms.loginform" /> <form-bean name="registrationform" type="de.forms.registrationform" /> </form-beans> Um eine FormBean nutzen zu können, sind zwei Schritte nötig und in der Konfigurationsdatei struts-config.xml zu konfigurieren. Zum einen müssen innerhalb des <form-beans>-tags alle genutzten FormBeans durch Name (logische Ressource) und Klasse (reale Ressource) eingebunden werden. Zum anderen muss die Bean in den Gültigkeitsbereich einer Action geholt werden. Dies geschieht innerhalb des ActionMappings (siehe Beispiel ActionMapping). Mit 10

11 Kapitel 3: Jakarta Struts dem Attribut name wird durch die logische Ressource die FormBean eingebunden. Mit dem Attribut validate wird festgelegt, ob das Validator-Framework die Daten des Formulare prüfen soll. Und mit dem Attribut scope wird der Zuständigkeitsbereich in Bezug auf das Servlet festegelegt (Session, Request). Die zentral definierten FormBeans können somit für mehrere Actions genutzt werden. 3.4 Struts View Die View wird durch JavaServer Pages repräsentiert. Tag-Bibliotheken erlauben Struts HTML-Output dynamisch zu gestalten. Es stehen zahlreiche Tag-Bibliotheken zur Verfügung, die verwendet werden können. Neben den Struts-eigenen wird in der Dokumentation die Verwendung der Java Standard Tag Library (JSTL) angeraten. In diesen Taglibs stehen dem Entwickler verschiedene Taggruppen zu Verfügung. Mit den Tags der Core-Gruppe der JSTL können Daten angezeigt werden, und mit der Formatierungsgruppe lassen sich die Tags länderspezifisch anpassen. Für die Dateieingabe in HTML-Formulare wird die Struts-HTML TagLib verwendet. In der HTML-TagLib befinden sich für alle HTML-Tags entsprechende Struts-Tags. taglib prefix="fmt" uri="/web-inf/lib/fmt.tld" %> taglib prefix="c" uri="/web-inf/lib/c.tld" %> taglib prefix="html" uri= /WEB-INF/lib/struts-html.tld" %> <fmt:setbundle basename="properties.messages_de" var="loc"/> <html:errors /> <html:form action="/userlogin"> <fmt:message key="login.username"/> <html:text property="username" size="25"/> <fmt:message key="login.password"/> <html:password property="login.password" size="25"/> <html:submit property="login"/> </html:form> Die Taglibs werden zu Beginn der JSP eingebunden. Das Beispiel beschreibt ein Login Formular mit zwei Eingabefeldern für Benutzername und Passwort. Formatierende HTML-Tags wurden weggelassen. Die hier verwendeten Tags der HTML-Tag-Lib arbeiten wie folgt: Das form-tag erzeugt ein HTML-Formular und ist damit das zentrale Tag der HTML-Tag-Lib von Struts. Mittels der Formulare werden die Benutzerdaten an den Server geschickt. Serverseitig repräsentiert eine FormBean den Inhalt des Formulars. Die Properties der FormBean werden über das property-attribut der Eingabefelder angesprochen. Das error Tag gibt alle Fehler aus, die im Struts-Context stehen (ActionErrors). Fehler, die während der Verarbeitung in der Action-Methode oder während der Validierung der Form- 11

12 Kapitel 3: Jakarta Struts Bean entstehen, können gesammelt, in den Struts-Kontext gelegt und über das html:error Tag als Fehlermeldungen auf der JavaServer Page ausgegeben werden. Die Ausgabe von Text durch das message-tag der Formatierungsgruppe ermöglichst eine lokalisierte Ausgabe. Die Lokalisierung ist der Prozess der Anpassung einer Applikation an eine bestimmte Sprache (Siehe Kapitel 4.9). Sämtliche sprachliche Ausgaben werden in zentrale Dateien (MessageBundle) ausgelagert. Die Texte werden über einen Schlüssel (key) referenziert. Soll die Sprache geändert werden, greift man auf ein anderes MessageBundle zurück. In dem JavaServer Pages Beispiel wird über das fmt:setbundle-tag die locale festgelegt und über das fmt:message-tag der Text der entsprechende Datei ausgegeben. 3.5 Validierung in Struts Struts bietet ein Validierungs-Framework, das eine serverseitige und optional eine clientseitige Auswertung mittels JavaScript unterstützt [BG04 S.125 ff]. Das Framework erlaubt eine deklarative Validierung außerhalb von Java, die in einer oder mehreren XML-Dateien konfiguriert wird. Hierfür können für ein Struts-Formular einfache Ausprägungsregeln der Eigenschaften, wie z.b. required, minlength, maxlenght definiert werden. Seit Struts 1.2 kann man zudem die Standardvalidatoren des Jakarta Common Validator-Projekts nutzen, die eine einfache Auswertung von Zahlentypen, Datumsangaben, u.s.w. ermöglicht. Entspricht eine Benutzereingabe nicht den Anforderungen der Regeln, so besteht die Möglichkeit, an entsprechender Stelle durch ein Error-Handling eine fehlerspezifische, festgelegte und internationalisierte Fehlermeldung in der View an entsprechender Stelle zu platzieren. Das ValidationFramework ist optional und wird über die Plugin-Schnittstelle in das Struts Framework eingebunden. Dazu wird ein entsprechendes Plugin-Tag in struts-config eingefügt. Das Framework ist zentral in Struts eingebunden und wird ausgeführt bevor die Action ausgeführt wird. Um das Framework zu nutzen, muss die FormBean von der Klasse VaidatorForm abgeleitet sein und die Methode validate() ausführen. Die Vorteile des Frameworks liegen zum einen in der Möglichkeit der clientseitigen Auswertung und zum andern in der leichten Anpassbarkeit und Erweiterbarkeit. Eine große Hilfe sind auch die Standardvalidatoren, die einen häufig genutzten Bereich abdecken. Sollten diese den Anforderungen nicht entsprechen, ist eine Erweiterung durch eigene Validatoren möglich. 3.6 Tiles-Layoutmanagement Das Tiles Layoutmanagement ermöglicht eine Trennung zwischen Layout und Inhalten der View. Dazu wird eine Seite in verschiedene Bereiche aufgeteilt. Alle wiederkehrenden Elemente und die Festlegung der Bereiche werden in einem Template-Layout festgelegt. Die 12

13 Kapitel 3: Jakarta Struts Templates sind dabei nichts anderes als JavaServer Pages, die an entsprechender Stelle Platzhalter Tile enthalten, in denen dann der dynamische Inhalt eingefügt wird. Welche Inhalte nun an die Stelle der Platzhalter eingefügt werden sollen, wird in einer XML-Datei festgelegt. Die Inhalte sind ebenfalls JavaServer Pages, nur sind diese viel übersichtlicher, weil sie wenig Layoutelemente enthalten. <tiles-definitions> <definition name="main.home" path="/mainframeworklayout.jsp"> <put name="leftboxcontent" value="/leftbox/home.jsp" /> <put name="mainboxcontent" value="/mainbox/home.jsp" /> </definition> <definition name="main.home2" extends="main.hone"> <put name="mainboxcontent" value="/mainbox/home2.jsp"/> </definition> </tiles-definitions> Unter dem Namen main.home ist das Template mainframeworklayout.jsp zu erreichen. In dem Layout sind die Bereiche left- und mainboxcontent enthalten, und der Pfad zu ihren Bereichsseiten definiert. Einzelne Definitionen kann man erweitern, indem man nur die sich ändernden Bereiche angibt. Dieses Framework ist voll in Struts integriert und wird wie das Validator Framework als Plugin in der struts-config eingebunden. Dieses Feature ermöglicht die Wahrung eines konsistenten und zentralisierten Layouts. Durch konsequente Verwendung von Tag-Bibliotheken erreicht man, dass sich in den JSP-Seiten kein Java-Code mehr befindet, sondern nur noch Tags. Mit der konsequenten Nutzung von Cascading-Style-Sheets lagert man den Hauptteil des Designs in separate Dateien aus. Mit dem Tiles- Layoutmanagement trennt man schließlich den Inhalt vom Layout. Diese Trennung von Inhalt, Layout und Design erbringt wesentliche Vorteile. Zum einen kann man viel Code wieder verwenden. Dieses hat zum anderen den Vorteil eines konsistenten und einheitlichen Aussehens der Anwendung. Des Weiteren werden die einzelnen JSP-Seiten übersichtlicher, leichter zu lesen und zu programmieren. Auf diese Weise kann sich der Entwickler auf die Erweiterung der Web-Anwendung mit Inhalt konzentrieren, ohne sich laufend um Design- und Layout-Elemente kümmern zu müssen. Ein Hauptvorteil ist sicherlich auch darin zu sehen, dass sich eine Änderung des Layouts und Designs keine Änderung in jeder einzelnen JSP nach sich zieht. 13

14 Kapitel 4: JavaServer Faces 4 JavaServer Faces Mit JavaServer Faces erweitert Sun die Java 2 Enterprise Umgebung um ein ereignisgesteuertes javabasiertes Web-Framework. Neben der vereinfachten Webseitengestaltung lag das Augenmerk der Entwickler auch darin, eine Tool-gestützte Web-Applikation-Entwicklung zu ermöglichen. Zudem unterliegt JSF im Rahmen des Java Community Process (JCP) einem Standardisierungs-Prozess. JSF besteht aus einem erweiterbaren UserInterface-Komponenten Model, einem flexiblen Rendering Model, einem Event Handling Model, einer Validierung und Konvertierung der Komponenten, einer grundlegende Seitennavigationsunterstützung und einer Lokalisierungsfähigkeit. Im Vergleich zu Struts zeigen sich viele Gemeinsamkeiten, aber auch grundlegende Unterschiede. Im Folgenden werden nun die MVC-Elemente von JSF vorgestellt und dann die Verarbeitung der Anfrage mit Hilfe des Lebenszyklus erklärt. Im Weiteren werden dann wichtige Elemente von Web-Frameworks vergleichend zu Struts vorgestellt. 4.1 MVC in Faces Die Controller-Komponente stellt bei JavaServer Faces das FacesServlet dar. Das Servlet ü- bernimmt die globale Steuerung, und dessen Verhalten wird in der zentralen Konfigurationsdatei faces-config.xml definiert. Die Datei enthält Tags, welche die Applikation steuern und definieren. In dem Applikation-Tag werden Einstellungen, die für die gesamte Applikation global gelten, festgelegt. Neben der Möglichkeit, den standardmäßigen Navigation-Handler oder View-Handler auszutauschen, werden hier Spracheinstellungen vorgenommen, die der Lokalisierung der Anwendung dienen. Hinterlegt ist diesem Element eine als Singleton implementierte Klasse, auf die zur Laufzeit zugegriffen werden kann, um globale Änderungen vorzunehmen. Mit dem Managed-Bean-Tag werden die Model-Komponenten eingebunden. Die Managed Beans sind JavaBeans, ähnlich der FormBeans bei Struts. Sie repräsentieren den serverseitigen Zustand der UI-Komponenten. Bei einer Anfrage stehen alle hier definierten Beans zur Verfügung. Die Managed Beans übernehmen im Gegensatz zu den Struts Form- Beans auch die Ausführung (Action), welche in Struts innerhalb der Actions ausgeführt wird. In dem Navigation-Rule Tag werden die Entscheidungsfälle für die Navigation definiert. Der Rückgabewert einer Model-Komponente legt dabei fest, welcher Navigationsfall ausgeführt werden soll. Die Steuerung übernimmt der Faces NavigationHandler. Werden für die Validierung und Konvertierung neue Klassen angelegt, so werden diese über das Validator- bzw. Converter-Tag eingebunden. Auf diese Weise werden alle benötigten Komponenten und Klassen in der faces-config eingebunden, so dass sie bei Bedarf genutzt werden können. 14

15 Kapitel 4: JavaServer Faces Die View-Komponente wird durch Renderer repräsentiert. Sie übersetzten die HTML TagLib- Elemente so, dass sie clientseitig von dem jeweiligen Browsertyp dargestellt werden. Java- Server Page ist nur eine Möglichkeit der Präsentation. Die Referenzimplementierung nutzt JSP als Standard sowie die Möglichkeit, HTML zu rendern. Allerdings werden weitere Renderertypen entwickelt, die z.b. WML oder Macromedia Flash ermöglichen. Dies ist dadurch möglich, dass alle UI-Elemente der View (Darstellung im Browser) auf UI-Komponenten (Java-Objekte) abgebildet werden. Beim Einlesen des Requests werden die UI-Elemente einer Seite auf einen UI-Komponenten-Baum abgebildet. Beim Zeichnen (rendern) der Elemente werden die UI-Komponenten durch den JSP-Renderer in HTML dargestellt und an den Browser zurückgesendet. 4.2 Der Lebenszyklus der Anfrageverarbeitung Abb.: Lebenszyklus der Anfrageverarbeitung Die JSF-Applikation erzeugt für jede neue Anfrage ein Objekt mit dem aktuellen Kontext (FacesContext). Eine Anfrage (Request) wird in diesen Kontext abgelegt und durchläuft den Standard-Lebenszyklus der Anfrageverarbeitung in JSF, bestehend aus 6 Phasen [HM04 S. 41 ff]. In der ersten Phase werden die UI-Elemente einer JSP-Seite auf einen Komponentenbaum abgebildet. Eine View besteht aus einer Menge einzelnen Komponenten, deren Validierungs- Klassen, Event-Listener und Konverter. Sobald der Komponentenbaum vollständig erzeugt wurde, werden in der zweiten Phase die Anfrage-Werte übernommen und zu den jeweiligen UI-Komponenten übertragen. In der dritten Phase werden die Benutzerangaben auf ihre formale Richtigkeit überprüft, um dann in der vierten Phase zu dem Model-Komponenten (Java- Beans) übertragen zu werden. In dieser Phase finden auch Konvertierungen statt, welche den übertragen Datentyp (String) aus dem HTML-Formular in den gewünschten Datentyp der UI- Komponente transformiert. In der fünften Phase wird die Anwendung ausgeführt, in dem die Action-Methode aufgerufen wird. Durch das zugehörige ActionEvent (z.b. Abschicken eines Formulares) wurde der Prozess der Anfrageverarbeitung angestoßen. Der Rückgabewert die- 15

16 Kapitel 4: JavaServer Faces ser Methode wird an den NavigationHandler übergeben, der daraufhin einen entsprechenden Navigation-Case aus der faces-config ausführt. Damit steht fest, welche Seite als nächstes ausgeführt wird und die Response wird in Phase 6 gerendert. Nach der 2. Phase wird die Verarbeitung immer wieder von der Event-Verarbeitung eines Phase-Events unterbrochen. An diesen Stellen kann der Entwickler den Prozess abbrechen und direkt zum Rendern der Response übergehen. Einen Abbruch kann es auch in den Phasen geben. Wenn z.b. die Validierung der Daten fehlschlägt, wird eine ValidatorException geworfen, Fehlermeldungen in den Faceskontext geschrieben und zur Ursprungsseite zurückverlinkt. Die Fehlermeldungen (FaceMessages) können dann auf der View wiedergegeben werden. Innerhalb der einzelnen Phasen (2, 3 und 4) können ebenfalls spezielle Events verarbeitet werden. Wie z.b. das ValueChangeEvent, welches dann ausgelöst wird, wenn ein Benutzer einen Wert in der View verändert hat. 4.3 JSF Tags View JSF wird mit zwei Tag Libraries ausgeliefert: jsf_core und html_basic. In jsf_core befinden sich Tags, die unabhängig von der jeweiligen Sprache (HTML,WML etc.) benutzt werden können. In html_basic sind alle Tags zur Darstellung der Standard HTML-Elemente zu finden. Um die Tag Libraries nutzen zu können, müssen sie auf der JSP-Seite eingebunden werden. Mit den Core Tags werden die wesentlichen Features von Faces, wie z.b. der Validator, die Konvertierung oder das Eventhandling eingebunden. Diese Features werden im Folgenden noch näher erklärt. In Struts ist das form-tag das zentrale Tag und in Faces ist es das view- Tag. Alle Faces Elemente innerhalb dieses Tags werden in den UI-Komponenten-Baum aufgenommen und stehen in Faces zur Verfügung. <%@ taglib uri=" prefix="h" %> <%@ taglib uri=" prefix="f" %> <html> <body> <f:view locale="de"> <h:form id="loginform"> Username: <h:inputtext id="username" value="#{loginbean.username}"/> Password: <h:inputsecret id="password" value="#{loginbean.password}"/> <h:commandbutton id="submit" action="#{loginbean.login}" value="#{message.submit}"/> </h:form> </f:view> </body> </html> Die html_basic Tag Library enthält Tags für alle Kombinationen aus UI-Komponenten und HTML Renderern, die durch die JSF-Spezifikation definiert wurden. Dazu gehören alle 16

17 Kapitel 4: JavaServer Faces HTML-Form-Elemente sowie andere Standard-Elemente. Die UIForm-Komponente wird durch das <h:form>-tag in HTML repräsentiert. Innerhalb des Tags können nun Eingaben- Elemente UIInput-Komponenten stehen. Über das commandbutton-tag wird das Formular schließlich abgeschickt. Wie man an dem Beispiel sieht, muss kein action-attribut angegeben werden. Die HTML-Attribute method und action eines Formulares werden von JSF automatisch generiert. Die UI-Command-Komponente führt eine Aktion aus, wenn sie aktiviert wird. Sie kann in Kombination mit einem HTML-Renderer die Ausprägungen commandbutton und commandlink annehmen. Über das action-attribut wird die Action-Methode der Managed- Bean referenziert. Diese Methode wird in Phase 5 des Lebenszyklus aufgerufen und ausgeführt. In dem Beispiel sind noch zwei UI-Input-Komponenten enthalten: Ein Standard- Eingabetextfeld und ein Passwort-feld. Über das value-attribut werden externe Datenquellen identifiziert. Man kann also über Value Binding Expressions auf die Properties eines Model-Objektes (JavaBean) zugreifen. 4.4 Managed Beans In der Faces Terminologie versteht man unter einer Managed Bean eine JavaBean mit einer Menge von Properties, die sich entweder auf Werte von UI-Komponenten beziehen oder direkt mit Instanzen dieser Komponenten verbunden sind. Des Weiteren können sie noch applikationsspezifische Methoden besitzen. Diese Methoden können der Validierung, der Konvertierung, dem Event Handling und der Vorbereitung der Navigation dienen. Die Daten, sowie die mit den Daten arbeitenden Methoden werden in einem Objekt gekapselt. So haben die Methoden einen einfachen Zugang zu den Daten. In Struts erfolgte die Ausführung in einer separaten Action-Klasse und die FormBean musste erst eingebunden werden. <managed-bean> <description>die Bean überprüft das Login </description> <managed-bean-name>loginbean</managed-bean-name> <managed-bean-class> de.myproject.model.loginbean </managed-bean-class> <managed-bean-scope>request</managed-bean-scope> </managed-bean> Sobald eine Anfrage eintrifft stehen alle, wie in dem Beispiel in der faces-config deklarierten Managed Beans zur Verfügung. Aus der JSP gibt es zwei Möglichkeiten, Werte einer Komponente mit Properties einer Bean zu verbinden. Value Binding Expressions werden in der JSF-Implementierung über die Klasse Value-Binding repräsentiert, welche ExpressionStrings der Form #{mybean.myproperty} nutzt und den Zugriff auf die Properties dieser Bean erlaubt. Bei der Nutzung ist vor allem darauf zu achten, dass der richtige Datentyp zwischen Bean und UI-Komponente ausgetauscht wird. Da in einer Webapplikation Benutzereingaben 17

18 Kapitel 4: JavaServer Faces nur als String übergeben werden können, besitzt Faces die Möglichkeit, Konverter einzubinden, die eine parametrisierte, automatische Konvertierung ermöglichen (siehe Konverierung). Dieses Verfahren wird ähnlich auch in Struts genutzt, aber Faces bietet noch eine weitere Verbindungsmöglichkeit: Die Instanzgebundenen Komponenten, welche das Komponentenmodel von Faces nutzen. Ein Property der Managed Bean ist in diesem Fall vom Typ der Komponente selbst. Die get()- und set()-methoden des Propertys liefern also eine Instanz der Komponente zurück. Der Vorteil der Instanzgebundenen Komponenten ist die volle Kontrolle des Entwicklers über die UI-Komponente. Bei der Method Binding Expression als Sonderform der Value Binding Expression werden nicht Properties einer Managed Bean gebunden, sondern ihre Methoden. Die Expressions ermöglichen bestimmten Events innerhalb von Faces beliebige public-methoden von Beans aufzurufen. Die Method Binding Expressions werden bei den Tag-Attributen action, action- Listener, validator und valuechangelisterner genutzt. Diese werden in den folgenden Kapiteln noch beschrieben. Nach den Zugriffsmöglichkeiten der View auf die ManageBean werden nun Zugriffsmöglichkeiten aus Sicht der Managed Bean aufgezeigt. Die Klasse FaceContext und die über diese Klasse referenzierten Klassen sind hier von zentraler Bedeutung. Dem FaceContext kann man FaceMessages über addmessage() zuweisen. Dies ermöglicht das Sammeln von Nachrichten und Fehlermeldungen, die dann über ein einfaches Tag in der View ausgegeben werden können. Weiter hat man Zugriff auf die Applikation-Instanz über getapplication(). Über diese Klasse kann man auf die global definierte Länderkennung locale und die länderspezifischen MessageBundle zugreifen und diese zur Laufzeit ändern. Zudem hat man über den FaceContext Zugriff auf den Komponentenbaum und seiner Wurzel, die UIViewRoot-Komponetente. Über den Zugang zu der UIViewRoot-Komponente kann auf den aktuellen Komponenten- Baum zugegriffen werden und sogar zur Laufzeit verändert werden. So können z.b. Komponenten einer JSP ein- und ausgeblendet werden. Der Zugriff auf den Komponentenbaum ist für den Entwickler ein sehr mächtiges Instrument. Diese direkte Manipulation der View gibt es in Struts nicht. So stellt sich Faces durch die Kombination aus Renderer und Manipulation des Komponentenbaums als mächtiger dar. 4.5 Validierung in Faces Für einfache Validierungsfälle wie z.b. die Überprüfung, ob eine Eingabe gemacht wurde, ob die Länge den Anforderungen entspricht oder ob die Eingabe ein numerischer Typ ist, liefert Faces Standardvalidatoren mit. Reicht diese recht dürftige Unterstützung durch Standardvalidatoren nicht aus, bieten sich in Faces mehrere Möglichkeiten der Erweiterung. 18

19 Kapitel 4: JavaServer Faces Durch Implementierung einer Validator-Methode innerhalb der Managed Bean muss keine eigene Validator-Klasse implementiert werden. In der Methode werden die notwendigen Validierungsregeln aufgenommen, und in dem entsprechenden Tag der JSP wird der Validator als Attribut aufgenommen. Dies ist bei allen Tags möglich, deren Komponenten von UI-Input abgeleitetet sind. <h:form> <h:messages style="color:red"/><br> <h:inputtext id="username" value="#{loginbean.username}" validator="loginbean.checkuser"/> </h:form> UI-Input-Komponenten liegen immer innerhalb eines Form-Tags und werden über ein UI- Command-Element abgeschickt. Damit wird die Verarbeitung gemäß dem gezeigten Lebenszyklus angestoßen. Die entsprechende Methode in der Managed Bean sieht demnach folgendermaßen aus: public void usercheck( FacesContext faces, UIComponent input, Object value) throws ValidatorException{ boolean Validierungsfehler = true; if (Validierungsfehler){ FacesMessage message = new FacesMessage( ); throw new ValidatorException(message); } } Bei einem Fehler wird eine FaceMessage erzeugt und eine Validatorexception mit dieser Message geworfen. Die UI-Komponente wird nun in einen Fehlerzustand gesetzt, die Nachricht im FacesContext gesammelt und der Lebenszyklus nach der Validierung abgebrochen, indem die entsprechende JSP wiederholt dargestellt wird. Die entstandenen Fehlermeldungen werden in diesem Beispiel mit Hilfe des <h:messages>-tag ausgegeben. Die einfache und unkomplizierte Validierung per Methode eignet sich immer dann, wenn die Validierung selten oder nur einmalig vorkommt. Kommt eine spezielle Validierung häufiger vor, lohnt sich meist der Mehraufwand, eine eigene Validierungsklasse zu erstellen. Eine Validierungsklasse implementiert das Interface Validator und muss die Methode validate enthalten. public class UserCheck implements Validator{ public void validate ( FacesContext faces, UIComponent input, Object value) throws ValidatorException { boolean Validierungsfehler = true; if (Validierungsfehler){ FacesMessage message = new FacesMessage( ); throw new ValidatorException(message); } } 19

20 Kapitel 4: JavaServer Faces Nach Erstellung der Klasse wird sie in der faces-config registriert, damit sie später über ein eigenes Validator-Tag genutzt werden kann. Die Regiestrierung erfolgt über das <validator>- Element: <validator> <validator-id>usercheck</validator-id> <validator-class>de.myproject.validator.usercheck </validator-class> </validator> Die Validator-id wird in den View-Komponenten durch das Validator-Tag, das bereits mit der Referenzimplementierung mitgeliefert wird, genutzt. <h:form> <h:messages style="color:red"/><br> <h:inputtext id="username" value="#{loginbean.username}"> <f:validator validatorid="checkuser"/> </h:inputtext> </h:form> Eine weitere Möglichkeit besteht darin, ein spezielles Custom Validator-Tag zu erstellen. Dies ist dann sinnvoll, wenn man das Validator-Tag noch mit Attributen erweitern möchte. So könnte man dem Validator ein Muster oder andere Parameter vorgeben. Damit erreicht man höchste Flexibilität in der Gestaltung der Validierung. Allerdings muss man zusätzlich zur Implementierung des Interfaces auch den Tag Handler um die Funktionalität erweitern. Die Flexibilität bezahlt man also mit einem bestimmten Maß an zusätzlicher Arbeit. Allerdings stellen sich die Validierungsmöglichkeiten als sehr flexibel dar und können somit evolutionär mit der Entwicklung eines Webframeworks entsprechend erweitert werden. 4.6 Konvertierung Bei Web-Applikationen gibt es zwei Sichten auf die Daten: Daten repräsentiert durch Datentypen innerhalb der Java-Objekte und Daten innerhalb der Präsentationssicht (Browser) repräsentiert durch einfachen Text. Daraus ergibt sich ein Konvertierungsproblem in Webapplikationen. Beispielweise wird ein in Textform angegebenes Datum auf der Präsentationsschicht zur Verarbeitung in dem Datentyp java.util.date umgewandelt werden. Die Konvertierung wird nach der Validierung in der Phase 4 im Lebenszyklus der Anfrage vorgenommen. Java Server Faces bietet eine Reihe von Standard-Konvertern, die automatisch eine Konvertierung vornehmen und dem Entwickler damit für die meisten Fälle die Arbeit abnehmen. Bei einigen muss noch nicht einmal ein Konverter explizit angegeben werden. Die in der Managed Bean enthaltenden get und set Methoden für die Properties können nun direkt die Daten vom Typ Integer oder Date des Beispieles einlesen und ausgeben, ohne sie selber konvertieren zu müs- 20

21 Kapitel 4: JavaServer Faces sen. Diese automatische oder anpassbare Lösung erleichtert die schnelle Implementierung von Webanwendungen. <h:inputtext id="intinput" value="#{mybean.intvalue}" required="true"/> <h:inputtext id="dateinput" value="#{mybean.mybirthday}" required="true"> <f:convertdatetime pattern="dd.mm.yyyy"/> </h:inputtext> Ist keine Konvertierung für einen Datentyp möglich, kann man, analog zur Vorgehensweise bei der Validierung, JSF um Konvertierungsmethoden oder Klassen flexibel erweitern. Als erstes kann man innerhalb der get und set Methode, den TextString manuell in den gewünschten Datentyp umwandeln und rückwandeln. Kommt eine bestimme Konvertierung häufiger vor, ist es sinnvoll durch Implementierung des Converter-Interfaces einen eigenen Konverter zu erstellen. Innerhalb dieses Konverters müssen zwei Methoden implementiert werden, welche die Um- und Rückwandlung übernehmen. Nach dem Einbinden des Konverters in der faces-config kann er durch das Standard-Validator-Tag <f:converter> genutzt werden. Für höchste Flexibilität besteht die Möglichkeit zudem noch ein Custom Converter-Tag mit spezifischen Attributen zu erstellen und eine angepasste Konvertierungsfunktionalität zu ermöglichen. Der Entwickler hat also auch hier die Möglichkeit zwischen einem einfachen Implementierungsaufwand und hoher Flexibilität und Wiederverwendbarkeit seiner Konvertierungsmethode zu wählen. Ein solches Konzept zur automatischen Konvertierung ist in Struts nicht vorhanden. Hier beweist JavaServer Faces durch hohe Flexibilität und vielfach automatisierten Konvertierungen gegenüber Struts einen klaren Vorteil. 4.7 Eventhandling In JavaServer Faces können von UI-Komponenten zwei Arten von Events ausgesendet werden: Action-Events und ValueChangeEvents. Die Events sind von der Klasse FacesEvent abgeleitet. Neben FacesEvents existiert noch die Klasse PhaseEvent. PhaseEvents werden von JSF nach Abarbeitung einer Phase der Anfrageverarbeitung versendet. Durch die Implementierung eines PhaseListeners und der Registrierung in der faces-config kann ein Entwickler diese Events empfangen. ActionEvents werden von Komponenten gesendet, die vom Typ UICommand sind. Das HTML RenderKit der Referenzimplementierung enthält die beiden Tags commandlink und commandbutton, welche Action-Events senden können. Beide implementieren alle das Interface ActionSource, welches nur die Methode actionperformed vorgibt. Auch hier besteht die Möglichkeit, ein Event innerhalb einer ActionEvent-Handling-Methode der Managed Bean zu verarbeiten oder eine eigene Event-Handling-Klasse zu implementieren. Um einen Action- 21

22 Kapitel 4: JavaServer Faces Listener an eine Komponente zu binden, wird entweder das <f:actionlisterner>-tag verwendet, um die Event-Handling-Klasse zu referenzieren oder das actionlistener-attribut des Tags der UICommand Komponente genutzt, um die ActionEvent-Handling-Methode der Managed Bean zu referenzieren. <h:form> <h:commandlink id="komando" action="#{mybean.doit}" actionlistener="#{mybean.showmyid}"/> </h:from> Der ActionListener empfängt bei Ausführung der Action ein ActionEvent und kann entsprechen darauf reagieren. Ein ActionEvent kann man z.b. dafür verwenden, die Sprache der Web Applikation zu ändern oder die ausgeführte Action in ein Logfile zu schreiben. public void showmyid(actionevent event){ String id = new String(event.getComponent().getId()); Log.debug(" Der CommandLink mit der ID " + id + "wurde ausgeführt"); } ValueChangeEvents werden ähnlich verarbeitet wie ActionEvents. Die entsprechenden Tags benutzen das Attribut valuechangelistener, um die Komponenten mit einer entsprechenden Methode der Managed Bean zu verbinden. Über ein valuechangeevent erfährt man zum einen, dass sich eine Komponente verändert hat und kann zudem auf den alten und neuen Wert der Komponente zugreifen. Innerhalb des <lifecycle>-tag in der faces-config können sogenanne PhaseListener registriert werden, die nach der Abarbeitung jeder Phase der Anfrageverarbeitung ein PhaseEvent empfangen. PhaseListener können für eine oder für alle Phasen registriert werden. Über PhaseEvents kann auf den aktuellen FacesContext zugegriffen werden und somit können die Phase- Listener für beliebige Erweiterungen (Logging, Zugangskontrolle etc.) verwendet werden. Gerade dieses ereignisgesteuerten Programmiermodel ermöglicht die in den Kapiteln Validierung und Konvertierung aufgezeigte Flexibilität. Dies stellt einen Vorteil im Vergleich zu Struts dar, welches nur eine einfache Abbildung von Anfragen auf Aktionen unterstützt. 4.8 Navigation Die Faces-Navigation oder die Navigation durch Aufruf des JSF NavigationsHandlers ist der Standardfall für die Navigation in der JSF-Applikation. Nach Verarbeitung der Action- Methode liefert diese einen String als Rückgabewert. Dieser String wird dem Navigation- Handler übergeben, der dann in den entsprechenden Navigationsregeln nach einer Weiterleitung sucht. Die Navigationsregeln werden in der faces-config definiert. Das navigation-rule- Tag umschließt eine Regel. Das from-view-id-tag legt fest, für welches view-element diese 22

23 Kapitel 4: JavaServer Faces Regel gilt (Vorgänger). Wird dieses Tag weggelassen, so gilt die Regel global. Mit beliebig vielen navigation-case-tags werden die Navigationsfälle definiert. Als Beispiel sei angenommen, dass je nach Erfolg loginerfolg oder loginfehler zurückgegeben wird. So könnte die Regel folgendermaßen lauten: <navigation-rule> <description>das Verhalten bei login</description> <from-view-id>/pages/myloginpage.jsp</from-view-id> <navigation-case> <description>login war erfolgreich</description> <from-outcome>loginerfolg</from-outcome> <to-view-id>/pages/mymainpage.jsp</to-view-id> </navigation-case> <navigation-case> <description>login ist fehlgeschlagen</description> <from-outcome>loginfehler</from-outcome> <to-view-id>/pages/myloginpage.jsp</from-view-id> </navigation-case> <navigation-rule> Bei Erfolg wird also auf die Hauptseite verwiesen und bei Misserfolg wiederum auf die Login-Seite. Hier könnten dann entsprechende Fehlermeldungen, wie Benutzername unbekannt, in den FacesKontext geschrieben werden und auf der View ausgegeben werden. Die Faces- Navigation stellt eine Reaktion auf die Geschäftslogik im weitesten Sinne dar. Das Navigationshandling ähnelt dem von Struts, der Unterschied liegt in der separaten Definition der Navigationsregeln und nicht innerhalb eines ActionMappings bezogen auf nur eine Action. 4.9 Lokalisierung Die Lokalisierung ist der Prozess der Anpassung einer Applikation an eine bestimmte Sprache oder Kultur und ist eines der wichtigsten Features heutiger Webframeworks. Wenn sämtliche Sprachelemente in einer Applikation fest kodiert sind, so ist eine Lokalisierung mit einem enormen Aufwand verbunden. Vorrausschauendes Programmieren kann diesen Aufwand sehr vereinfachen. In Struts und Faces nutzt man RessouceBundles. Sämtliche sprachliche Ausgaben werden dabei in zentrale Dateien ausgelagert. Die Texte werden über einen Schlüssel referenziert. Nun ist es nur noch nötig, für jede zu unterstützende Sprache eine solche Datei zu erstellen. Die Dateien haben die Form resources_de.properties für deutsche Texte, resources_en.properties für englische Texte u.s.w.. Wird eine locale nicht unterstützt, so fällt die Sprachausgabe automatisch auf eine dafür definierte locale zurück. Um also eine weitere Sprache zu unterstützen, schickt man einen ResourcenBundle einfach zum Übersetzer. Die Unterstützung ist in Struts und Faces gleich. 23