JavaJEEJSF

Introduction

Most importantly JavaServer Faces technology provides a rich architecture for:

• model-view-controller architecture
• managing component state
• processing component data,
• validating and convert user input
• support for internationalizing
• handling events.

Nach einer fast dreijährigen Spezifikationsphase und etlichen damit verbundenen Diskussionen hat Sun 2004 das erste offizielle Release der JSF-Spezifikation (Java Server Faces) veröffentlicht. You can think of JSF as "swing for server-side applications". Compared to that servlets and JSP are the assmebly language.

JSF has three parts:

• a set of prefabricated UI components
• an event-driven programming model
• a component model that enables third-party developers to supply additional components

Eine dargestellte Seite heißt im JSF-Kontext View. Dieser besteht aus hierarchisch angeordneten Komponenten der Benutzerschnittstelle, etwa einfachen Eingabefeldern und Knöpfen, aber auch aufwendigeren Bausteinen wie Tabellen, Bäumen und Menüs. Diese Struktur bildet in ihrer Summe einen Baum, dessen Hierarchie den Seitenaufbau widerspiegelt. So kann eine Tabelle beispielsweise wieder Ein- oder Ausgabefelder enthalten und ein Menü eventuell Untermenüs. Für jeden Benutzer der Webanwendung speichert das Framework eine entsprechende Instanz des Komponentenbaums.

Jede Komponente kann der Programmierer mit einer ID versehen und auf diese Weise ansprechen oder suchen. Grundsätzlich kann sie einen beliebigen Zustand besitzen und diesen über Request-Grenzen hinaus speichern. Dabei ist sowohl eine Speicherung auf dem Client als auch auf dem Server möglich. Alle Komponenten sind von der abstrakten Klasse UIComponent abgeleitet, der wesentlichen Schnittstelle zum Komponentenbaum. Die Wurzel des Baums bildet eine Instanz des Typs UIViewRoot.

Fast alle Eigenschaften einer Komponente lassen sich mit „Value Bindings“ versehen, um den aktuellen Wert an einen bestimmten Speicherort zu binden. Mit Hilfe solcher Bindings können zum Beispiel Eingabefelder ihre Daten im Modell speichern und wieder daraus lesen. In der Regel speichert eine Eingabekomponente zusätzlich den übertragenen Wert lokal, um diesen unabhängig von Konvertierungen im Fehlerfall wieder anzeigen zu können. Dieses geschieht für den Entwickler einer JSF-Seite transparent, das heißt, ohne ihm zusätzlichen Aufwand zu verursachen.

Nimmt der Server einen Faces Request entgegen, verarbeitet er diesen gemäß des Request-Lebenszyklus (Request Processing Lifecycle, RPL) in sechs Phasen:

• Restore View
• Apply Request Values
• Process Validations
• Update Model Values
• Invoke Application
• Render Response

Java Server Faces sind ausgabeunabhängig. Wie eine Komponente auf dem Client erscheint, wie eine Anwendung ihre Parameter kodiert und dekodiert, entscheidet ein zugeordneter „Renderer“. Für die Ansteuerung der Renderer sorgt ein ViewHandler. Für HTML definiert der JSF-Standard eine JSP-Tag-Library.

Derzeit stehen zwei etablierte Implementierungen für die JSF-Spezifikation zur Verfügung. Zum einen die von Sun herausgegebene Referenzimplementierung und zum anderen die unter der Apache-2.0-Lizenz stehende JSF-Implementierung MyFaces, die eine gute Alternative zu der Sun-eigenen Variante ist.

Implementation

Libs

• add libs jsf-api.jar, jsf-impl.jar and jstl.jar

Configuration Files

web.xml

• add the following entries

<servlet>
  <display-name>FacesServlet</display-name>
  <servlet-name>FacesServlet</servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>FacesServlet</servlet-name>
  <url-pattern>*.jsf</url-pattern>              // maps all *.jsf request to the Faces Servlet
</servlet-mapping>

The src page has to be named *.jsp because its still a JSP page with JSF tags in it.

faces-config.xml

• location in <WAR-File>\WEB-INF\ directory (beside web.xml)

<faces-config>

  <managed-bean>
    <managed-bean-name>user</managed-bean-name> // this name can be used in jsf pages
    <managed-bean-class>...</managed-bean-class>
    <managed-bean-scope>...</managed-bean-scope>
  </managed-bean>

  <NAVIGATION_RULES>

</faces-config>

JSF pages

There is one JSF page for each browser screen. A page starts with tag library declarations:

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

inputSecret

<h:inputSecret value="<VALUE>" required="[true|false]">

Navigation

Static navigation can be specified in the faces-config.xml via navigation rules. In the jsf page use this:

<h:commandButton value="Login" action="login_action"/>

and in the faces-config.xml write:

<navigation-rule>
  <from-view-id>/jsf_login.jsp</from-view-id>
  <navigation-case>
    <from-outcome>login_action</from-outcome> // action name specified in h:commandButton action="..."
    <to-view-id>/jsf_welcome.jsp</to-view-id>
  </navigation-case>
</navigation-rule>

To implement dynamic navigation the command button must have a method expression:

<h:commandButton value="Login" action="#{loginController.verifyUser}"/>

The return type of the method is converted to a string to look up a matching navigation rule.

Managed Beans

You can specify a bean scope (see here):

• session, beans are not thread-safe
• application
• request, beans are inherently thread-safe

Sometimes it is convenient to design a bean that contains some or all components objects of a web form, called backing bean. This is useful for e.g. validating relationships between multiple components. To use the backing bean you use the binding attribute in jsf pages.

In typical Seam applications there are no jsf managed beans.

Applications

Core JSF Examples

s. Sources

/Uwes/eclipse/workspace/corejsf/ant -Dapp=ch1/login and so on.

Sources

• Core JavaServer Faces; David Geary & Cay Horstmann; source code in C:\Uwes\Zips\Java\JSF\corejsf2-examples.zip; http://corejsf.com and extracted to <ECLIPSE_WORKSPACE>\corejsf\.