Traitement et navigation

12
Traitement et navigation
Au chapitre précédent, nous avons vu comment créer des pages web avec différentes
technologies (HTML, JSP, JSTL, etc.) en insistant sur le fait que JSF est la spéci-
cation conseillée pour écrire des applications web modernes avec JavaEE. Cepen-
dant, créer des pages contenant des composants graphiques ne suft pas: ces pages
doivent interagir avec un backend (un processus en arrière-plan), il faut pouvoir
naviguer entre les pages et valider et convertir les données. JSF est une spécica-
tion très riche: les beans gérés permettent d’invoquer la couche métier, de naviguer
dans votre application, et, grâce à un ensemble de classes, vous pouvez convertir les
valeurs des composants ou les valider pour qu’ils correspondent aux règles métiers.
Grâce aux annotations, le développement de convertisseurs et de validateurs person-
nalisés est désormais chose facile.
JSF 2.0 apporte la simplicité et la richesse aux interfaces utilisateurs dynamiques.
Il reconnaît nativement Ajax en fournissant une bibliothèque JavaScript permettant
d’effectuer des appels asynchrones vers le serveur et de rafraîchir une page par parties.
La création d’interfaces utilisateurs, le contrôle de la navigation dans l’application
et les appels synchrones ou asynchrones de la logique métier sont possibles parce
que JSF utilise le modèle de conception MVC (Modèle-Vue-Contrôleur). Chaque
partie est donc isolée des autres, ce qui permet de modier l’interface utilisateur
sans conséquence sur la logique métier et vice versa.
Le modèle MVC
JSF et la plupart des frameworks web encouragent la séparation des problèmes en
utilisant des variantes du modèle MVC. Ce dernier est un modèle d’architecture
permettant d’isoler la logique métier de l’interface utilisateur car la première ne se
© 2010 Pearson Education France – Java EE 6 et GlassFish 3 – Antonio Goncalves

386 Java EE 6 et GlassFish 3
mélange pas bien avec la seconde: leur mélange produit des applications plus dif-
ciles à maintenir et qui supportent moins bien la montée en charge. Dans la section
"JavaServer Pages" du chapitre précédent, nous avons vu une page JSP qui contenait
à la fois du code Java et des instructions SQL: bien que ce soit techniquement cor-
rect, imaginez la difculté de maintenir une telle page... Elle mélange deux types de
développement différents (celui de concepteur graphique et celui de programmeur
métier) et pourrait nir par utiliser bien plus d’API encore (accès aux bases de don-
nées, appels d’EJB, etc.), par gérer les exceptions ou par effectuer des traitements
métiers complexes. Avec MVC, l’application utilise un couplage faible, ce qui faci-
lite la modication de son aspect visuel ou des règles métiers sous-jacentes sans
pour autant affecter l’autre composante.
Comme le montre la Figure12.1, la partie "modèle" de MVC représente les données
de l’application; la "vue" correspond à l’interface utilisateur et le "contrôleur" gère
la communication entre les deux.
Figure12.1
Le modèle
de conception MVC.
Client
Server
Contrôleur
(FacesServlet)
Modèle
(backing bean)
Vue
(pages XHTML)
Navigateur
Requête HTTP
Réponse HTTP
manipule et redirige
crée et gère
accède
Le modèle est représenté par le contenu, qui est souvent stocké dans une base de
données et afché dans la vue; il ne se soucie pas de l’aspect que verra l’utilisateur.
Avec JSF, il peut être formé de backing beans, d’appels EJB, d’entités JPA, etc.
La vue JSF est la véritable page XHTML (XHTML est réservé aux interfaces web,
mais il pourrait s’agir d’un autre type de vue, comme WML pour les dispositifs
mobiles). Comme au chapitre précédent, une vue fournit une représentation gra-
phique d’un modèle et un modèle peut avoir plusieurs vues pour afcher un livre
sous forme de formulaire ou de liste, par exemple.
Lorsqu’un utilisateur manipule une vue, celle-ci informe un contrôleur des modi-
cations souhaitées. Ce contrôleur se charge alors de rassembler, convertir et valider
les données, appelle la logique métier puis produit le contenu en XHTML. Avec JSF,
le contrôleur est un objet FacesServlet.
© 2010 Pearson Education France – Java EE 6 et GlassFish 3 – Antonio Goncalves

Chapitre 12 Traitement et navigation 387
FacesServlet
FacesServlet est une implémentation de javax.servlet.Servlet qui sert de contrô-
leur central par lequel passent toutes les requêtes. Comme le montre la Figure12.2,
la survenue d’un élément (lorsque l’utilisateur clique sur un bouton, par exemple)
provoque l’envoi d’une notication au serveur via HTTP; celle-ci est interceptée
par javax.faces.webapp.FacesServlet, qui examine la requête et exécute diffé-
rentes actions sur le modèle à l’aide de beans gérés.
Figure12.2
Interactions de
FacesServlet.
Cycle de vie
FacesContext
FacesServlet
Bouton Événement
2. Passe le contrôle au cycle de vie
3. Traitement en 6 étapes
1. Crée un FaceContext
En coulisse, la FacesServlet prend les requêtes entrantes et donne le contrôle à
l’objet javax.faces.lifecycle.Lifecycle. À l’aide d’une méthode fabrique, elle
crée un objet javax.faces.context.FacesContext qui contient et traite les infor-
mations d’état de chaque requête. L’objet Lifecycle utilise ce FacesContext en six
étapes (décrites au chapitre précédent) avant de produire la réponse.
Les requêtes qui doivent être traitées par la FacesServlet sont redirigées à l’aide
d’une association de servlet dans le descripteur de déploiement. Les pages web, les
beans gérés, les convertisseurs, etc. doivent être assemblés avec le chier web.xml
du Listing12.1.
Listing12.1: Fichier web.xml dénissant la FacesServlet
<?xml version=’1.0’ encoding=’UTF-8’?>
<web-app version="2.5"
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-app_2_5.xsd">
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
© 2010 Pearson Education France – Java EE 6 et GlassFish 3 – Antonio Goncalves

388 Java EE 6 et GlassFish 3
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
</web-app>
Ce chier dénit la javax.faces.webapp.FacesServlet en lui donnant un nom
(Faces Servlet, ici) et une association. Dans cet exemple, toutes les requêtes por-
tant l’extension .faces sont associées pour être gérées par la servlet – toute requête
de la forme http://localhost:8080/ chapter10-1.0/newBook.faces sera donc
traitée par JSF.
Vous pouvez également congurer quelques paramètres spéciques à JSF dans
l’élément <context-param> (voir Tableau12.1).
Tableau12.1: Paramètres de conguration spéciques à JSF
Paramètre Description
javax.faces.CONFIG_FILES Dénit une liste de chemins de ressources liées au
contexte dans laquelle JSF recherchera les ressources.
javax.faces.DEFAULT_SUFFIX Permet de dénir une liste de sufxes possibles pour les
pages ayant du contenu JSF (.xhtml, par exemple).
javax.faces.LIFECYCLE_ID Identie l’instance LifeCycle utilisée pour traiter les
requêtes JSF.
javax.faces.STATE_SAVING_
METHOD
Dénit l’emplacement de sauvegarde de l’état. Les
valeurs possibles sont server (valeur par défaut qui
indique que l’état sera généralement sauvegardé dans un
objet HttpSession) et client (l’état sera sauvegardé
dans un champ caché lors du prochain envoi de
formulaire).
javax.faces.PROJECT_STAGE Décrit l’étape dans laquelle se trouve cette application
JSF dans le cycle de vie (Development, UnitTest,
SystemTest ou Production). Cette information peut être
utilisée par une implémentation de JSF pour améliorer les
performances lors de la phase de production en utilisant
un cache pour les ressources, par exemple.
javax.faces.DISABLE_FACELET_
JSF_VIEWHANDLER
Désactive Facelets comme langage de déclaration de
page (PDL).
javax.faces.LIBRARIES Liste des chemins qui seront considérés comme une
bibliothèque de marqueurs Facelets.
© 2010 Pearson Education France – Java EE 6 et GlassFish 3 – Antonio Goncalves

Chapitre 12 Traitement et navigation 389
FacesContext
JSF dénit la classe abstraite javax.faces.context.FacesContext pour représenter
les informations contextuelles associées au traitement d’une requête et à la produc-
tion de la réponse correspondante. Cette classe permet d’interagir avec l’interface
utilisateur et le reste de l’environnement JSF.
Pour y accéder, vous devez soit utiliser l’objet implicite facesContext dans vos
pages (les objets implicites ont été présentés au chapitre précédent), soit obtenir
une référence dans vos beans gérés à l’aide de la méthode statique getCurrentIns-
tance(): celle-ci renverra l’instance de FacesContext pour le thread courant et vous
pourrez alors invoquer les méthodes du Tableau12.2.
Tableau12.2: Quelques méthodes de FacesContext
Méthode Description
addMessage Ajoute un message d’erreur.
getApplication Renvoie l’instance Application associée à cette application
web.
getAttributes Renvoie un objet Map représentant les attributs associés à
l’instance FacesContext.
getCurrentInstance Renvoie l’instance FacesContext pour la requête traitée par le
thread courant.
getMaximumSeverity Renvoie le niveau d’importance maximal pour tout
FacesMessage mis en le d’attente.
getMessages Renvoie une collection de FacesMessage.
getViewRoot Renvoie le composant racine associé à la requête.
release Libère les ressources associées à cette instance de FacesContext.
renderResponse Signale à l’implémentation JSF que le contrôle devra être
transmis à la phase Render response dès la n de l’étape de
traitement courante de la requête, en ignorant les étapes qui n’ont
pas encore été exécutées.
responseComplete Signale à l’implémentation JSF que la réponse HTTP de cette
requête a déjà été produite et que le cycle de vie du traitement de
la requête doit se terminer dès la n de l’étape en cours.
© 2010 Pearson Education France – Java EE 6 et GlassFish 3 – Antonio Goncalves