3 Schnelleinstieg in die Entwicklung mit JSF *

Transkript

1 25 3 Schnelleinstieg in die Entwicklung mit JSF * Die Entwicklung mit JSF stellt sich etwas anders dar, als die Entwicklung mit Servlets oder JSPs. JSF ist ein Framework basierend auf dem Model 2-Konzept. Die Entwicklung mit JSF ist weiter von der darunter liegenden Webtechnik entfernt, als Sie es von der Java-Webentwicklung mit Servlets und JSP-Seiten gewohnt sind. Obwohl die Verwendung von JSTL bereits eine Möglichkeit darstellt, bis zu einem gewissen Grad von den technischen Details einer Webapplikation zu abstrahieren, versucht JSF hier noch einen Schritt weiter zu gehen. Bei JSTL sind Sie es z. B. gewohnt, Tags zu verwenden, die hauptsächlich die Aufgabe haben, bestimmte Teile des XHTML zu rendern. Bei JSF verwendet man Komponenten, die zwar ähnlich einfach wie die Tags zu verwenden sind, jedoch noch mehr Möglichkeiten bieten, als Sie das von einfachen JSTL-Tags gewohnt sind. Ein weiterer Punkt ist, dass Sie bei einer einfachen Webarchitektur direkt auf die View (also die Servlets und JSP-Seiten, die das HTML rendern) zugreifen. Man spricht hierbei auch von Model 1-Webanwendungen. Im Gegensatz dazu wird bei JSF nicht direkt auf die View zugegriffen, sondern indirekt über ein sogenanntes Front- Controller-Servlet. Das heißt, der Benutzer ruft nicht direkt eine JSP-Seite auf, sondern zunächst das Front-Controller-Servlet, welches wiederum die JSP-Seite aufruft und das gerenderte XHTML an den Benutzer zurückgibt. Hierbei spricht man von Model 2-Webanwendungen. Diese Webanwendungen sind an das von der Fatclient-Entwicklung bekannte MVC-Pattern angelehnt ( Model View Controller). Da sich dieses Pattern jedoch nicht eins zu eins auf Webanwendungen anwenden lässt, spricht man hierbei manchmal auch vom MVC-2-Pattern. Die folgenden Kapitel erklären die wesentlichen Ansätze und grundlegenden Techniken von JSF:»Model 1-Webanwendungen«, S. 26»Model 2-Webanwendungen«, S. 28»Aufbau einer JSF-Webanwendung«, S. 31 Unterschiede zur Entwicklung ohne JSF

2 26 3 Schnelleinstieg in die Entwicklung mit JSF *»Einführung in JSF-Tags«, S. 34»Einführung in Value Bindings«, S. 37»Einführung in Managed Beans«, S. 39»JSF ist ein Model 2 Framework«, S Model 1-Webanwendungen * Bei Model 1-Webanwendungen greift der Client direkt auf die entsprechenden Views, also die JSP-Seiten und Servlets, die das XHTML generieren, zu. Die Ablaufsteuerung der Webanwendung von Seite zu Seite wird über eine direkte Verlinkung realisiert. Das heißt, dass 1.jsp beispielsweise einen Link rendert, der auf 2.jsp verweist. Dieser Ablauf wird in der Abb illustriert. Abb : Ablauf Model 1. Schritt 1 Der Client ruft die Seite 1.jsp auf. Diese Seite nutzt eine Instanz der Klasse Benutzer, um dort Daten zu hinterlegen. Um die Klasse Benutzer zu nutzen, instantiiert 1.jsp ein Objekt der Klasse und speichert dort Daten ab, die aus dem Request ermittelt wurden (»befüllen«).

3 3.1 Model 1-Webanwendungen * 27 Anschließend generiert die JSP-Seite ein entsprechendes XHTML-Dokument als Antwort und liefert dieses an den Client zurück. Dieses generierte XHTML enthält einen Link auf 2.jsp. Der Benutzer klickt diesen Link an (Schritt 2) und ruft 2.jsp Schritt 2 auf. Diese Seite nutzt ebenfalls das von 1.jsp erzeugte Objekt der Klasse Benutzer und generiert wiederum XHTML. Dieses XHTML wird anschließend an den Client zurückgelie- Schritt 3 fert. Üblicherweise besteht eine Model 1-Webapplikation (aus der Client-Sicht gesehen) ausschließlich aus JSP-Seiten bzw. Servlets. Das hat zur Folge, dass die JSP-Seiten und Servlets nicht nur als View, sondern auch als Controller genutzt werden. JSP-Seiten erfüllen hier also nicht nur die Aufgabe, XHTML zu rendern (als reine View), sondern rufen auch die Geschäftslogik auf, instantiieren die auf der Seite benötigten Beans und bestimmen, welche JSP-Seite als nächste angezeigt wird (Ablaufsteuerung). Bei den vorgenannten Aufgaben handelt es sich um Dinge, die üblicherweise von einem Controller erledigt werden. Die JSP-Seiten erledigen also auch folgende (Controller-) Aspekte: Applikations/Geschäftslogik Ablaufsteuerung Instantiieren/Befüllen der benutzten Beans Zwangsläufig entstehen dadurch bei zunehmender Größe der Applikation immer komplexere JSP-Seiten und Servlets, da keine strikte Trennung zwischen den einzelnen Aufgabengebieten besteht. Es besteht die Gefahr, den Überblick zu verlieren und eine schwer wartbare Anwendung zu erschaffen. Das bedeutet nicht, dass der Model 1-Ansatz grundsätzlich abzulehnen ist. Bei kleinen Anwendungen oder Prototypen, die nach der Präsentation verworfen werden, kann Model 1 ein effizientes Vorgehen ermöglichen. Bei größeren Anwendungen, die über einen längeren Zeitraum gewartet werden sollen, ist Model 1 eher unzureichend. Hier muss eine stärkere Trennung der einzelnen Aufgabengebiete erfolgen. Diese Problematik adressiert Model 2. Technischer Aufbau Einschränkungen Fazit

4 28 3 Schnelleinstieg in die Entwicklung mit JSF * 3.2 Model 2-Webanwendungen * Bei Model 2-Webanwendungen erfolgt der Zugriff des Clients nicht wie bei Model 1 direkt auf die JSP-Seiten oder Servlets, sondern immer auf den Front-Controller der Webanwendung. Üblicherweise greift der Client direkt auf eine JSP-Seite oder ein Servlet zu. Bei Model 2-Anwendungen gibt es hingegen eine zentrale Stelle, die stattdessen aufgerufen wird und den Aufruf an das Ziel-Servlet oder die Ziel-JSP-Seite weiterleitet. Diese zentrale Stelle, die der Client aufruft, ist meist ein Servlet. Wegen dieser Aufgabe innerhalb der Webanwendung wird es Front-Controller-Servlet genannt. Dieses Servlet generiert selbst in der Regel kein XHTML, sondern nutzt dazu andere JSP-Seiten innerhalb der Anwendung, auf die der Client keinen direkten Zugriff hat. Der Client merkt prinzipiell nichts von diesem Vorgehen. Die Abb stellt dar, wie dieselbe Anwendung, die bei Model 1 dargestellt wurde (siehe»model 1-Webanwendungen«,S.26),miteinerModel 2-Architektur funktioniert. Abb : Ablauf Model 2.

5 3.2 Model 2-Webanwendungen * 29 Vergleichen Sie diese Grafik mit der Abb Es ist klar zu erkennen, dass Aufgaben, die vorher von jeder JSP-Seite einzeln erledigt wurden, jetzt durch das Front-Controller- Servlet durchgeführt werden. In der Abb sieht man, dass der Benutzer nicht mehr direkt auf die JSP-Seiten zugreift. Stattdessen ruft er immer das Front-Controller-Servlet auf, das wiederum die JSP-Seiten nutzt. Beim ersten Aufruf nutzt das Front-Controller-Servlet die Seite 1.jsp und liefert das von der Seite erstellte XHTML zurück. Bei dem zweiten Aufruf wird (durch den Klick auf den Link) wieder das Front-Controller-Servlet aufgerufen, dieses Mal nutzt das Servlet jedoch 2.jsp und liefert das entsprechende XHTML zurück. Bei der Model 2-Webanwendung wird außerdem das Instantiieren und Befüllen der Bean-Objekte vom Front-Controller-Servlet übernommen, sodass dies nicht mehr in den Views implementiert werden muss. Durch die zentrale Rolle des Front-Controller-Servlets ist es einfach festzulegen, welche JSP-Seite wann aufgerufen werden soll (Ablaufsteuerung). Model 2 ist übrigens nicht darauf festgelegt, JSP-Seiten zu verwenden, um das XHTML zu generieren. Genauso gut wäre es möglich, eine andere Art von Dateienzuverwenden,diedenView beschreiben (beispielsweise XML-Dateien wie bei Facelets). Falls Sie sich schon einmal mit dem Thema Model 2-Webanwendungen beschäftigt haben, kann es sein, dass Ihnen die Abb , die noch einmal die generelle Funktionsweise von Model 2-Webanwendungen erläutert, bekannt vorkommt. Diese Abbildung verdeutlicht den gerade besprochenen Verlauf noch einmal etwas allgemeingültiger und nicht konkret auf ein Beispiel bezogen. Der Benutzer kommuniziert mit dem Front-Controller, er schickt also seine Requests direkt dorthin und erhält von ihm seine Responses. Der Front-Controller instantiiert und befüllt das Model. Anschließend ruft er seine JSP-Seiten auf, die das entsprechende XHTML generiert und dazu Zugriff auf die von dem Front- Controller instantiierten Beans hat. Vergleich mit Model 1 Kein direkter Zugriff auf JSP-Seiten Instantiieren und Befüllen durch Front- Controller Ablaufsteuerung Allgemeingültige Definition

6 30 3 Schnelleinstieg in die Entwicklung mit JSF * Abb : Ablauf Model 2 (generell). Fazit Der wichtigste Unterschied zur Model 1-Architektur ist die klare Abgrenzung der einzelnen Aufgabenbereiche. Dadurch lassen sich entsprechende Code-Teile leichter lokalisieren und es sinkt das Risiko, dass Sie einen unwartbaren»klops«entwickeln. Wenn man sich die letzten beiden Abbildungen ansieht, stellt man fest, dass viele Funktionen des Front-Controllers eher allgemeiner Natur sind und nur lose mit der Applikationslogik zusammenhängen. Deshalb ist es durchaus denkbar, einen universellen Front-Controller zu verwenden, der mittels einer Konfigurationsdatei an die speziellen Applikationsbedürfnisse angepasst werden kann. Diese Konfigurationsdatei enthält dann Informationen wie Navigationsabläufe (von welcher Seite wird auf welche andere verwiesen) oder Informationen über das zu instantiierende Model. Sie müssen solch einen allgemeingültigen Front-Controller nicht selbst entwickeln. Hier setzen Java- Webframeworks wie JSF an und liefern Ihnen einen allgemeinen Front-Controller (neben vielen weiteren Annehmlichkeiten).

7 3.3 Aufbau einer JSF-Webanwendung * Aufbau einer JSF-Webanwendung * JSF-Anwendungen unterscheiden sich in ihrem grundsätzlichen Aufbau etwas von den gewohnten Java-Webanwendungen. Zum Vergleich einer JSF-Webanwendung mit einer Standard- Java-Webanwendung sehen Sie in der Abb den grundsätzlichen Aufbau einer JSF-Webanwendung. Grundsätzlicher Aufbau Abb : Aufbau einer JSF-Webapplikation. Die Grafik unterscheidet sich etwas von einer Standard-Java-Webanwendung. Da es sich hierbei um eine Model 2-Webanwendung handelt, erfolgt der Zugriff ausschließlich auf das Faces Servlet und nicht mehr direkt auf die JSP-Seiten. Beim Faces Servlet handelt es sich um das zuvor erwähnte Front-Controller-Servlet (siehe»model 2-Webanwendungen«, S. 28). Dieses wird durch JSF bereitgestellt. Neben der web.xml, die von jeder Java-Webanwendung benötigt wird, gibt es eine weitere Konfigurationsdatei namens faces-config.xml. Benötigt wird diese von dem Faces Servlet. Zwar übernimmt das Faces Servlet nur allgemeine Aufgaben wie das Instantiieren der Model-Klassen und das Aufrufen der JSP-Seiten, jedoch ist es natürlich applikationsabhängig, wann welche JSP-Seiten aufgerufen und wann welche Klas- Vergleich

8 32 3 Schnelleinstieg in die Entwicklung mit JSF * sen instantiiert werden sollen. Genau diese Informationen liefert die faces-config.xml-datei. Beispiel Benutzer.java index.jsp Damit diese Unterschiede etwas greifbarer werden, lernen Sie im Folgenden die Webapplikation, welche bereits in den Ausführungen zu Servlet und JSP/JSTL vorgestellt wurde, nun als JSF-Applikation kennen. Model-Klasse: Facesconfig.xml package org.w3l.jsf; public class Benutzer { private String name; public String getname() { return name; } } public void setname(string name) { this.name = name; } JSP-Seite: <%@taglib prefix="f" uri=" <%@taglib prefix="h" uri=" <html> <body> <f:view> <h:form> <h:inputtext value="#{benutzer.name}"/> <h:commandbutton value="senden"/> </h:form> <h:outputtext value="#{benutzer.name}" rendered="#{benutzer.name!=null}" /> </f:view> </body> </html> Konfigurationsdatei: <faces-config version="1.2" xmlns=" xmlns:xsi=" xsi:schemalocation=" <managed-bean> <managed-bean-name>benutzer</managed-bean-name> <managed-bean-class> org.w3l.jsf.benutzer

9 3.3 Aufbau einer JSF-Webanwendung * 33 </managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> </faces-config> Wenn Sie sich den Inhalt der JSP-Seite ansehen, stellen Sie fest, dass auch hier JSP-Tags und Expression Language verwendet werden. Es handelt sich jedoch nicht um dieselben Tags, wie sie in dem JSP/JSTL-Beispiel verwendet wurden, sondern um spezielle, JSF-spezifische Tags. Diese werden gleich erklärt. Die Syntax der Expression Language ist grundsätzlich gleich, unterscheidet sich nur insofern, dass die Ausdrücke bei JSF durch ein»#«eingeleitet werden, statt mit einem»$«. Die Faces-config.xml definiert ein Objekt vom Typ Benutzer (managed-bean-class), das unter dem Namen benutzer (managed-bean-name) zur Verfügung gestellt wird und so innerhalb der JSP-Seite verwendet werden kann. Die Abb verdeutlicht, welche Tags für welche Teile der Anwendung zuständig sind. Erläuterung Abb : Schematische Darstellung der JSF-Beispielapplikation. Die Abbildung zeigt die Anwendung, nachdem etwas eingegeben (»test«) und die»senden«-schaltfläche betätigt wurde. Der eingegebene Text wurde bereits unten ausge-

10 34 3 Schnelleinstieg in die Entwicklung mit JSF * geben. Die Abb zeigt einen Screenshot der Beispielapplikation. Abb : Screenshot der JSF-Beispielapplikation. Versuchen Sie, die Beispielanwendung lokal zu starten. 3.4 Einführung in JSF-Tags * Tags sind aus gewöhnlichen XHTML-Seiten bekannt. JSF- Tags sind komplexere Konstrukte, die dazu dienen, eine JSF-Seite aufzubauen. Es existieren einige JSF-Tags, die eine direkte visuelle Entsprechung haben. Dazu zählen die Tags inputtext, commandbutton und outputtext. Es gibt jedoch auch Tags,die über keine visuelle Entsprechung verfügen, z. B. die Tags view und form. Zunächst lernen Sie die visuellen Tags kennen. Beispiel index.jsp Im Folgenden wird sich auf das Beispiel aus dem Kapitel»Aufbau einer JSF-Webanwendung«, S. 31, bezogen, das hier nochmals wiederholt wird: JSP-Seite: <%@taglib prefix="f" uri=" <%@taglib prefix="h" uri=" <html> <body> <f:view> <h:form> <h:inputtext value="#{benutzer.name}"/> <h:commandbutton value="senden"/> </h:form> <h:outputtext value="#{benutzer.name}" rendered="#{benutzer.name!=null}" /> </f:view> </body> </html>

11 3.4 Einführung in JSF-Tags * 35 Mit dem inputtext-tag können Benutzereingaben entgegengenommen werden. Dieses Tag wird in Form eines Textfeldes ausgegeben. Das value-attribut bezeichnet, wo die Benutzereingabe gespeichert werden soll (dazu später mehr). Mit dem commandbutton-tag wird dem Benutzer eine Möglichkeit angeboten, seine eingegebenen Daten an den Server zu übermitteln und/oder auf dem Server eine Aktion auszuführen. Dieses Tag wird in Form einer Schaltfläche ausgegeben. Das value-attribut gibt an, welchen Text die Schaltfläche trägt. Mit dem outputtext-tag wird dem Benutzer ein Text angezeigt. Der auszugebende Text wird in dem value-attribut definiert. In dem Beispiel ist es der Text, den der Benutzer mit dem inputtext-tag übermittelt hat (dieser Tag benutzt denselben Wert als»value«wie der inputtext-tag). Das Attribut»rendered«gibt an, ob die Komponente gerendert wird, also ob das entsprechende XHTML produziert wird oder nicht. Hier wird sie nur gerendert, falls der Benutzer bereits einen Text eingegeben hat (das Value Binding also nicht null ist). Wie erwähnt gibt es Tags ohne visuelle Entsprechung, die dennoch notwendig sind und einen rein technischen Zweck erfüllen. Der form-tag entspricht dem, was Sie bereits aus XHTML als form-tag kennen. Um mit XHTML ein Formular, also Benutzereingaben, an den Server zu senden, benötigen Sie ein form-tag, das alle zu übermittelnden Formularelemente umgibt. Das JSF-Form-Tag entspricht diesem 1:1 und wird tatsächlich auch als XHTML-Form-Tag gerendert. Sie müssen auch dieses form-tag analog zum XHTML-Form-Tag um alle JSF-Tags legen, die eine Benutzereingabe übermitteln. Deshalb umschließt der Tag in dem Beispiel zwar das inputtext- Tag (welches Benutzereingaben übermittelt), jedoch nicht das outputtext-tag (welches ausschließlich Text ausgibt). Das view-tag hat einen ganz besonderen Status. Es wird auf jeder JSF-Seite benötigt und muss alle anderen JSF-Komponenten umschließen. Es hat in der Regel keine XHTML-Repräsentation, das heißt, es rendert überhaupt nichts. Der Grund dafür, dass dieses Tag dennoch benötigt wird, erfahren Sie später, da dies etwas detailliertere Kenntnisse des Frameworks verlangt. Zum jetzigen Zeitpunkt ist nur wichtig zu InputText-Tag CommandButton- Tag OutputText-Tag Form-Tag View-Tag

12 36 3 Schnelleinstieg in die Entwicklung mit JSF * Tag vs. Komponente wissen, dass dieses Tag auf jeder Seite benötigt wird und immer alle anderen JSF-Tags umschließen muss. Die verwendeten JSF-Tags wurden nur angerissen. Es gibt viele andere Attribute, die diese Tags anbieten. Vielleicht ist Ihnen aufgefallen, dass in den Beschreibungen der einzelnen Tags manchmal von Tag und manchmal von Komponente die Rede war. Bei einer typischen, reinen JSTL/JSP-Lösung spricht man ausschließlich von Tags. Bei JSF sind es jedoch nicht nur Tags, die verwendet werden. Der Tag ist vielmehr nur ein Bindeglied zwischen JSP-Seite und Komponente. Die Komponente liefert die eigentliche Funktionalität. Geht es also um die Komponente im Allgemeinen, also z. B. das Rendering der Komponente oder bestimmte Funktionsweisen, spricht man von einer Komponente. In der Abb ist der Aufbau einer JSF-Komponente illustriert. Vergleichen Sie diese Abbildung mit der des JSP-Tags (Abb ). Abb : Aufbau einer JSF-Komponente. Hier fungiert der JSP-Tag nur als eine Art Platzhalter für die eigentliche Komponente. Im Sinne der JSP kann man also noch von einem Tag sprechen. Im JSF-Kontext spricht man

13 3.5 Einführung in Value Bindings * 37 häufig aber von der dahinterliegenden Komponente, die hier auch das Rendern des XHTMLs übernimmt. In JSF werden die Tags also nur als Platzhalter in JSPs genutzt. Man spricht beispielsweise davon, einen Tag in die JSP-Seite einzufügen. Spricht man hingegen über das Rendern von XHTML, bezieht man sich in der Regel auf die Komponente. Verglichen mit einfachen Tags, die Sie von JSPs kennen, verfügen Komponenten über mehr Möglichkeiten. Sie werden später mehr über diese Möglichkeiten erfahren, die einen wichtigen Teil von JSF ausmachen. 3.5 Einführung in Value Bindings * Value Bindings ermöglichen über eine einfache Beschreibungssprache den Zugriff auf Objekte und deren Attribute aus JSF-Seiten heraus. Value Bindings sind Ausdrücke die Sie aus der Expression Language bereits kennen. Der Ausdruck #{benutzer.name} bezieht sich auf das Attribut name des Objektes benutzer, welches in einem beliebigen Scope liegen kann. BeiJSFsprichtmanhierbeivoneinemValue Binding. EinValue Binding unterscheidet sich etwas von einem Expression Language-Ausdruck, den Sie von der JSP-Technik kennen. Das Value Binding basiert aber ebenfalls auf der Expression Language. Ein Expression Language-Ausdruck ist bei JSP-Seiten eine Einbahnstraße: Er wird immer nur gelesen. Was auf der einen Seite eine Einschränkung ist, eröffnet auf der anderen Seite Möglichkeiten. Während man sich bei einem Ausdruck wie #{benutzer.name} vorstellen kann, ihn sowohl zu lesen als auch zu schreiben (also das Attribut name entweder zu lesen oder zu schreiben), ist das bei einem Ausdruck wie #{benutzer.name!=null} nicht möglich. Während das Lesen eines solchen Ausdrucks möglich ist, ist das Schreiben nicht möglich. Was sind Value Bindings? Eigenschaften der Expression Language

14 38 3 Schnelleinstieg in die Entwicklung mit JSF * Eigenschaften von Value Bindings Wozu werden Value Bindings genutzt? Ein Value Binding kann in beide Richtungen funktionieren. Bei einfachen Ausdrücken wie #{benutzer.name} kann geschrieben und gelesen werden, bei vergleichenden Ausdrücke wie #{benutzer.name!=null} kann nur gelesen werden. Value Bindings werden bei JSF unter anderem dazu genutzt, um Eingabekomponenten mit Objekten, beziehungsweise deren Attribute, zu verknüpfen. Ändert sich der Wert der Eingabekomponente (beispielsweise der Komponente h:inputtext), wird auch das Attribut des Value Bindings entsprechend geändert. Die Abb zeigt diesen Zusammenhang. Abb : Ablauf: Value Bindings. Schritt 1: Der Benutzer trägt etwas in die Eingabekomponente ein und übermittelt die Eingabe durch einen Klick auf die Schaltfläche. Schritt 2: JSF leitet die von dem Benutzer gemachten Eingaben an die Komponente weiter. Schritt 3: Die Komponente wertet diese Eingaben aus und wird Benutzereingaben als Wert des Value Bindings speichern. Durch dieses Vorgehen ist es nicht nötig, den vom Benutzer eingegebenen Wert selbst aus der Komponente auszulesen und in einem Objekt zu speichern.

15 3.6 Einführung in Managed Beans * 39 Dieses Prinzip funktioniert übrigens auch in der entgegengesetzten Richtung. Ändert sich das Attribut des Objektes, ändert sich auch der Wert der Komponente bei der Darstellung. Man kann hier also wirklich von einem Binding zu Deutsch Bindung sprechen. 3.6 Einführung in Managed Beans * Managed Beans sind Objekte, die von JSF automatisch instantiiert werden und dann in einem bestimmten Scope zur Verfügung stehen. Konfiguriert werden sie in der faces-config.xml, in der die Managed Bean-Klasse und der Scope festgelegt werden. JSF wird bei dem ersten Zugriff auf ein Objekt unter einem bestimmten Namen (z. B. benutzer) einobjektderentspre- chenden Klasse instantiieren und in einem Scope speichern. Voraussetzung hierfür ist, dass die zu instantiierende Klasse über einen public-konstruktor verfügt, der ohne Parameter aufgerufen werden kann. Es ist offensichtlich, dass JSF anhand eines Value Bindings wie #{benutzer.name} nicht wissen kann, von was für einem Typ das Objekt benutzer ist, also welche Klasse instantiiert werden muss oder in welchem Scope dieses Objekt gespeichert werden soll. Diese Informationen müssen zusätzlich hinterlegt werden. Dies geschieht in der faces-config.xml. Bei solchen Objekten, welche automatisch durch JSF instantiiert und in einem Scope gespeichert werden, spricht man von Managed Beans. Die Konfiguration erfolgt in der faces-config.xml daher auch im Managed Beans-Abschnitt. Hier werden alle nötigen Informationen über die jeweilige Managed Bean festgelegt. Hierzu zählt der Name, unter dem diese Managed Bean in Value Bindings und Expression Language Ausdrücken referenziert wird, genauso wie die Klasse, die instantiiert werden soll, und der Scope, inder das instantiierte Objekt gespeichert wird. Die Abb zeigt, wie der Ablauf aussieht, wenn eine Managed Bean das erste Mal in einem Value Binding referenziert wird. Einführung Was ist eine Managed Bean? Ablauf

16 40 3 Schnelleinstieg in die Entwicklung mit JSF * Abb : Ablauf Managed Bean. Der Ablauf stellt sich wie folgt dar: Schritt 1: Eine Komponente (hier inputtext) muss die Expression #{benutzer.name} auflösen. Dazu wird diese Komponente JSF benutzen und übermittelt die Expression an das Framework. Schritt 2: Im nächsten Schritt wird JSF versuchen, das Objekt, um das es hier geht (benutzer), in einem Scope zu finden. JSF wird alle drei Scopes (in der Reihenfolge: Request, Session, Application) nachdiesemobjektdurchsuchen. Da es sich hierbei um die erste Frage nach diesem Objekt handelt, findet JSF es nicht. Daraufhin wird es durch JSF instantiiert. Dazu benötigt JSF jedoch weitere Informationen über dieses Objekt. Zumindest muss klar sein, um welche Klasse es sich handelt, die instantiiert werden soll, und in welchem Scope das Objekt abgelegt werden soll.

17 3.6 Einführung in Managed Beans * 41 Schritt 3: Diese Informationen entnimmt JSF der facesconfig.xml. Schritt 4: Nachdem JSF die Informationen ermittelt hat, wird die Klasse instantiiert. Schritt 5: Dieses Objekt wird in dem entsprechenden Scope gespeichert. Schritt 6: Die Komponente erhält den gewünschten Wert benutzer.name. Der Vorgang wurde etwas vereinfacht dargestellt. Konkrete technische Details finden Sie späterin»derjsf-lebenszy- klus«, S. 183, und»jsf-erweiterungen«, S Eine faces-config.xml, dieeinemanaged Bean definiert, wird im Folgenden gezeigt. <faces-config version="1.2" xmlns=" xmlns:xsi=" xsi:schemalocation=" <managed-bean> <managed-bean-name>benutzer</managed-bean-name> <managed-bean-class> org.w3l.jsf.benutzer </managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> </faces-config> Die Konfigurationsdatei ist vor dem bereits erklärten Hintergrund weitgehend selbsterklärend. Konfigurationsdatei facesconfig.xml Beispiel In einer faces-config.xml-datei können beliebig viele Managed Beans konfiguriert werden. Eine Managed Bean besteht üblicherweise mindestens aus folgenden Elementen: managed-bean-name: Legt fest, unter welchem Namen die Bean im Scope gespeichert und in Expressions referenziert wird. managed-bean-class: Legt fest, welchen Typ das neu erstellte Objekt haben soll. managed-bean-scope: Legt fest, in welchem Scope das Objekt (die Managed Bean) gespeichert werden soll.

18 42 3 Schnelleinstieg in die Entwicklung mit JSF * Front- Controller- Servlet Im Beispiel wird also bei dem Zugriff auf die Managed Bean benutzer die Klasse org.w3l.jsf.benutzer instantiiert und diese Instanz im Session Scope gespeichert. Auch hier gibt es noch eine Vielzahl an weiteren Konfigurationsmöglichkeiten, Sie finden diese später in»managed Properties«, S. 63, und»komplexe Managed Properties«, S JSF ist ein Model 2 Framework * JSF ist ein Model 2-Framework dies ist einfach an dem zentralen Front-Controller-Servlet zu erkennen, das bei JSF Faces-Servlet heißt. JSF funktioniert wie eine Model 2-Anwendung (siehe»model 2-Webanwendungen«, S. 28). Anstelle eines Front-Controller-Servlet gibt es bei JSF ein Faces-Servlet. Sämtliche Ein- und Ausgaben erfolgen bei JSF, wie für Model 2-Anwendungen im Allgemeinen üblich, über das Front-Controller-Servlet, hier Faces-Servlet genannt. Wenn Sie gleich im Anschluss die Webanwendung ausprobieren, werden Sie mit Ihrem Browser also nicht direkt auf die JSP-Seiten zugreifen, sondern nur indirekt über das Faces-Servlet. Dies ist unbedingt nötig und wird meist automatisch von Konfiguration der web.xml Ihrer Entwicklungsumgebung in der web.xml konfiguriert. Ohne das Einrichten des Faces-Servlets in der web.xml ist es nicht möglich, eine JSF-Seite zu nutzen. Vergleich mit Model 2 Die Abb zeigt eine modifizierte Model 2-Abbildung, welche den Ablauf einer JSF-Anwendung noch einmal schematisch darstellt. Hier ist deutlich zu erkennen, dass das Faces-Servlet eine sehr zentrale Rolle einnimmt. Die Abbildung zeigt deutlich, dass die Unterschiede zur Model 2-Abbildung nur marginal sind.

19 Abb : Ablauf der JSF-Beispielanwendung. 3.7 JSF ist ein Model 2 Framework * 43

20