JavaServer Faces : présentation
1. JavaServer Faces
1. 1 Framework MVC2
JSF (JavaServer Faces ou simplement Faces) est un frameWork MVC2 qui permet la conception de composants d''interfaces utilisateur' (UI - user Interface) réutilisables. Tout Serveur d'applications au sein duquel s'exécute une application JSF permet, de façon transparente , l'accès aux bases de données, l'utilisation de Listener, l'utilisation de gestionnaires d'événements (Events) et des annotations.
 |
| figure 1.0 |
Dans JSF le Modèle est un ensemble de classes Java et/ou de beans gérés (voir définition des managed-beans), les Vues (Views) des Facelets (voir définition des Facelets) le tout sous la houlette du Contrôleur, une Servlet unique appelée FacesServlet.
La Servlet FacesServlet intercepte les requêtes HTTPs et organise leurs traitements. JSF dispose de fonctionnalités pour la validation et la conversion des données portées par les différentes requêtes issues des Vues. Les Backings beans (Beans gérés associés à des vues), qui sont de simples POJOs, servent à récupérer les valeurs des données présentes dans les requêtes et les formulaires issus des vues (Facelets).
Chaque application développée avec le framework JSF possède, comme toute application java développée avec une ou plusieurs servlets, un fichier descripteur de déploiement appelé web.xml; en plus de ce fichier avec JFS on dispose aussi d' un certain nombre de fichier (fichier xml) de configuration; exemple on a faces-config.xml qui sert à définir des règles de navigation entre les différentes pages web ou de configurer des propriétés de certains javaBeans.
Pour les vues (des pages web - Facelets), depuis JSF 2.0, on privilégie l'utilisation des Facelets un langage de balises issues de l'association de HTML et XML en place et lieu des autres langages comme JSP.
1. 2 Les objectifs de JavaServer Faces
La JSR 127 spécifie 8 exigences qui sont au cœur de toute évolution et développement des différentes versions de JSF depuis la JSF 2.0 :
- Créer un framework standard de composants UI (Interfaces Utilisateurs) qui peut servir de levier pour développer rapidement et facilement des composants logiciels permettant de créer à la fois des Interfaces Utilisateur de très grandes qualités et de gérer la connexion des UIs des applications web java.
- Définir un ensemble de simples classes java de base légères pour les composants des interfaces utilisateurs; ces classes tiennent compte de l'état des autres composants (voir la classe ComponentState) et des événements d'entrée. Ces classes, de façon transparente, intégreront la gestion du cycle de vie des UIs, notamment la gestion des états persistant d'un composant pour la durée de vie de sa page.
- Fournir un ensemble commun de composants UIs, y compris pour les éléments standard d'entrée pourtyle="background-color: #fef86c;" les formulaires HTML. Ces composants dériveront des UIs définis conformément au framework standard précisé en 1.
- Fournir un modèle de JavaBeans pour distribuer toute forme d’événement du côté des UIs des pages clientes vers le Serveur d'applications.
- Définir des APIs pour la validation des données d'entrée, y compris la validation côté client.
- Spécifier un modèle pour l'internationalisation et la localisation de l'interface utilisateur.
- Fournir pour la génération automatique pour les données de sortie, celles appropriées pour le client cible, en tenant compte de toutes les données de configuration disponibles du client , telles que la version du navigateur.
- Fournir pour la génération automatique pour les données de sortie, celles qui tiennent compte des nécessités pour supporter l'accessibilité, telle qu'elle est définie par la Web Accessibility Initiative (WAI ).
2. Structure d'une application JSF
2. 1. JSF un nouveau standard Java
La technologie JSF permet de mettre en relation des éléments existant déjà dans Java JEE. Cela veut tout simplement dire que JSF est juste un standard de Java JEE pour les applications web avec quelques configurations spécifiques.
- Chaque application web Java possède un fichier de configuration "web.xml" et chaque entrée dans ce fichier exécute le Contrôleur; pour JSF c'est la Servelt FacesServlet qui est le contrôleur; quand un modèle d'URL lui est associé comme "/faces/*" par exemple, il l’exécute. Lorsqu'on développe une application JSF 2.O dans un serveur d'application contenant l' API Servlet 3.0, le fichier web.xml est optionnel. Si on est dans ce cas de figure la Servlet FacesServlet est automatiquement "mappée" pour les modèles d'URLs /faces/*, *.jsf et *.faces.
- Un fichier de configuration optionnel pour les applications JSF, le fichier faces-config.xml, permet de configurer les éléments de l'application JSF. Dans JSF on a à peu près une Annotation pour tout élément susceptible d'être mis dans le fichier de configuration faces-config.xml; ainsi on élimine l'utilisation du fichier web.xml dans la plupart des cas. On met ce fichier faces-config.xml, dans une application web JSF, dans le répertoire WEB-IN/ (voir la structure d'une application JSF).
- Quand une application web s’exécute dans un serveur qui ne support pas nativement JSF, on rajoute les librairies qui composent JSF dans le répertoire "WEB-INF/lib".
Toute application web développée avec la JSF est constituée d' un ensemble de fichiers tels que:
- les fichiers ".xhtml" - ce sont les facelets i.e les vues -,
- les managed Beans - pour les Backing bean un par vue en général -,
- les EJB (stateless ou stateful, singleton) - pour la logique métier -
- et les EJB entities - pour les données -.
Dans les Facelets on se sert de EL (langage d'expressions) une technologie qui permet de transmettre aux Managed Beans les données des requêtes présentes dans les formulaires des facelets ainsi que des tags issues directement des Libraries de tags de Java EE, de HTML ou de core (tags spécifiques de JSF).
Pour se servir des tags dans les facelets on ajoute dans les en-têtes des Facelets des directives comme suit:
< html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:f="http://xmlns.jcp.org/jsf/core">
L'URI de l'espace de nom XML permet de localiser les librairies de tags et le préfixe (exemple "h" pour HTML et "f" pour JSF) précise le type de tag concerné. Il existe d'autres préfixes pour d'autres librairies de tags. Par exemple, pour une tag spécifique à JSF on utilise le préfixe f comme suit <f...> et pour le tag spécifique à "HTML" <h:form...>.
3. Les fichiers de configuration
3. 1. Le fichier descripteur de déploiement web.xml
Toute application web en java (si on n'utilise pas l' API Servlet 3.0 ou plus) a besoin d'un fichier descripteur de déploiement; ce fichier s'appelle web.xml et réside dans le répertoire WEB-INF/. Dans sa spécification, ce fichier XML doit contenir tout ce dont a besoin un serveur dans une application web, excepté ce qui concerne le "context path" (le contexte path est fourni par l'administrateur de l'application au moment ou celle-ci est déployée).
3.1.1. Les principaux éléments de web.xml
Les paramètres de configuration concernent,
- la description de l'application (elle est gérée par deux balises ;<display-name> qui permet de fournir un nom à l'application et < description> qui permet de décrire l'application),
- l'Inventaire de toutes les Servlets utilisées dans l'application (chaque Servlet est désignée par un nom compris entre les balises <servlet-name> et </servlet-name>, plus la classe qui implémente la Servlet - elle est comprise entre les deux balises <servlet-class> et </servlet-class> -),
- le mapping des Servlets (sert à indiquer au serveur quelle servlet chargée pour telle requête du client - tetyle="background-color: #fef86c;"lle URL demandée-)
Le tag <servlet> définit la servlet utilisée comme contrôleur dans l'application. C'est javax.faces.webapp.FacesServlet.
Le tag <load-on-startup> avec comme valeur 1 demande le chargement de la Servlet FacesServlet au lancement de l'application.
Le tag <servlet-mapping> précise le mapping des URLs qui seront traitées par la servlet.
Ce mapping peut prendre deux formes:
mapping par rapport à une extension : exemple <url-pattern>*.faces</url-pattern>.
mapping par rapport à un préfixe : exemple <url-pattern>/faces/*</url-pattern>.
Les URLs utilisées pour des pages mettant en oeuvre JSF doivent obligatoirement passer par la Servlet FacesServlet. Ces URLs peuvent être de deux formes selon le mapping défini. Le paramètre de contexte javax.faces.STATE_SAVING_METHOD permet de préciser le mode d'échange de l'état de l'arbre des composants de la page. Deux valeurs sont possibles : client ou server ; Il est possible d'utiliser l'extension .jsf pour les fichiers JSP utilisant JSF à condition de correctement configurer le fichier web.xml dans ce sens. Pour cela deux choses sont à faire:
il faut demander le mapping des URLs terminant par .jsf par la servlet
<servlet-mapping> <servlet-name>jsp </servlet-name> <url-pattern>*.jsf </url-pattern> </servlet-mapping>
il faut préciser à la servlet le suffixe par défaut à utiliser
<context-param> <param-name> javax.faces.DEFAULT_SUFFIX </param-name> <param-value>.jsf </param-value> </context-param>
3.2. Exemple de fichier web.xml
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>Example</display-name> <description>Example Application</description> <context-param> <param-name>javax.faces.CONFIG_FILES</param-name> <param-value> /WEB-INF/test1-faces-config.xml, /WEB-INF/test2-faces-config.xml, /WEB-INF/test3-faces-config.xml </param-value> </context-param> <servlet> <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>*.faces</url-pattern> </servlet-mapping> </web-app>
3. 3. Le fichier de configuration faces-config.xml
Ce fichier de configuration permet de définir des règles de navigation entre les pages web, des paramètres de configuration pour les JavaBeans, les validators ou pour différents composants de l'application JSF. Chaque élément présent dans le fichier de configuration "faces-config.xml" d'une application web JSF peut-être remplacé par une annotation au sein des java Beans de l'application. Ce fichier "faces-config.xml" est généralement placé dans le répertoire WEB-INF/ de l'application.
3.4. Les principaux éléments de faces-config.xml
( à faire).
3.4.1. Exemple de fichier faces-config.xml
<?xml version='1.0' encoding='UTF-8'?> <faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0"> <application> <locale-config> <default-locale>fr</default-locale> </locale-config> <resource-bundle> <base-name>message</base-name> <var>msg</var> </resource-bundle> </application> <navigation-rule> <from-view-id>*</from-view-id> <navigation-case> <from-outcome>doCreateBook-success</from-outcome> <to-view-id>/listBooks.htm</to-view-id> </navigation-case> </navigation-rule> </faces-config>
L'en-tête de ce fichier "xml" (voir la partie en gras dans le fichier "faces-config.xml") donne un certain nombre de précision sur le schéma XML du fichier et et un certain nombre d'espaces de nom qui seront utilisés dans l'application notamment par les facelets.
4. Fonctionnement d'une application web avec JSF
4.1. Cycle de vie d'une requête JSF
Le cycle de vie d'une application concerne toutes les étapes de l'application du début à la fin. Durant les différentes étapes du cycle de vie, différentes tâches sont exécutée :
- Phase de restauration des vues (Restore view): dans cette phase le serveur recrée l'arborescence des composants qui forment la page; Cette arborescence est stockée dans un objet de type FacesContext et est utilisée tout au long du traitement de la requête
- Fixation des valeurs des paramètres (Apply Request Values Phase): dans cette étape, les valeurs des données sont extraites de la requête HTTP pour chaque composant et sont stockées dans leur composant respectif dans le FaceContext. Durant cette phase des opérations de conversions sont réalisées pour permettre de transformer les valeurs stockées sous forme de chaînes de caractères dans la requête http en un type utilisé pour le stockage des données.
- Vérification des valeurs pour la validation jsf (Process Validations Phase): une fois les données extraites et converties, il est possible de procéder à leur validation en appliquant les validators enregistrés auprès de chaque composant. Les éventuelles erreurs de conversions sont stockées dans le FaceContext. Dans ce cas, l'étape suivante est directement « Render Response » pour permettre de réafficher la page avec les valeurs saisies et afficher les erreurs
- Copie des valeurs dans les beans. validation lors de la copie (Update Model Values Phase): cette étape permet de stocker dans les composants du FaceContext leurs valeurs locales validées respectives. Les éventuelles erreurs de conversions sont stockées dans le FaceContext. Dans ce cas, l'étape suivante est directement « Render Response » pour permettre de réafficher la page avec les valeurs saisies et d' afficher les erreurs
- Exécution de la commande (Invoke Application Phase): dans cette étape, le ou les événements émis dans la page sont traités. Cette phase doit permettre de déterminer la page résultat qui sera renvoyée dans la réponse en utilisant les règles de navigation définie dans l'application. L'arborescence des composants de cette page est créée
- Création du résultat (Render Response Phase): cette étape se charge de créer le rendue de la page de la réponse
Le cycle de vie d'une requête/réponse avec JSF se présente de deux aspects différents:
le Premier aspect concerne une requête qui est soumise pour la première fois et le deuxième concerne une requête qui est déjà soumise.
(à suivre )...
