JavaServer Faces Facile - e

Composants logiciels
JavaServer Faces Facile
JJLC
Introduction.
JavaServer Faces (JSF) est un framework JAVA, pour le développement d'applications Web. Le
projet de ce cadriciel (framework) a démarré en 2004. Il est dirigé par une communauté JAVA, un
Java Community Process1 (JCP). Ses spécifications sont consignées dans un document, un Java
Specification Requests (JSR).
Les versions de JSF sont spécifiées par les JSR suivants :
- JSF 1.0 : JSR 127 (2004),
- JSF 1.2 : JSR 252 (2006),
- JSF 2.02 : JSR 314 (2009),
- JSF 2.1 : JSR 314 (2010),
- JSF 2.2 : JSR 344 (2013),
chacune de ces versions a donné lieu à la production d'une implémentation de référence. La
première version a été réalisée par une communauté de développeurs au sein de l'entreprise Sun
Microsystem appelée JSF RI (JSF Reference Implementation). Puis à partir de la version JSF 1.2,
la communauté a changé de nom pour s'appeler Mojarra. Après le rachat de Sun Microsystem par
la société Oracle, la communauté Mojarra3 a gardé son nom.
C'est l'implémentation de référence Mojarra qui est utilisée sous la forme de librairies JAVA comme
première couche dans les applications réalisées avec JSF. Cette couche implémente les composants
de base du langage HTML sous la forme de composants graphiques (widget) JSF appelés
UIComponents. Ceux-ci permettent de décorer les pages WEB (Vues) et d'interagir avec des
composants JAVA appelés ManagedBean qui en représentent le Modèle. A ce titre JSF possède une
architecture MVC24.
Les composants graphiques possèdent un cycle de vie complexe qui leur permet d'évoluer dans un
système avec état (statefull). C'est à dire que l'état d'un composant graphique de type
UIComponent est enregistré lors du rendu (notion de renderer) de la page pour être ensuite restauré
au retour de la requête HTTP. A noter également que la version JSF 2.2 intègre la technologie
AJAX de façon native.
Cependant d'autres éditeurs fournissent des composants JSF de plus haut niveau. Comme par
exemple des systèmes de menu, de calendrier, de traitement de texte, de présentation multimédia,
d'adaptation au terminaux mobiles, etc.
1 Un JCP regroupe un certain nombre d'experts et les entreprises parties prenantes du projet
2 La version JSF 2.0 coïncide avec celle de la plateforme JAVA EE 6.
3 Communauté Mojarra : https://javaserverfaces.java.net/
4 MVC2 : méta-patron de conception MVC (Modèle, Vue, Contrôleur) adapté au WEB (mapping HTTP-Objet et
contrôleur unique)
1/7 Composants Logiciels JJLC

Voici la liste de ces fournisseurs qui proposent quasiment tous leur produit en licence libre et Open
source :
- le produit RichFaces de l'éditeur JBoss propriété de REDHAT,
- le produit ICEFaces de l'éditeur ICESoft Technologies Inc,
- le produit OpenFaces de l'éditeur TeamDev Ltd,
- les produits Trinidad, Tobago et Tomahawk de l'éditeur Apache Foundation,
- le produit PrimeFaces de l'éditeur Prime Tek Informatics,
- le produit ADF de l'éditeur Oracle,
- le produit XPages de l'éditeur IBM,
tous ces produits doivent être utilisés en plus de l'implémentation de référence Mojarra. Ils sont
distribués sous la forme de librairies JAVA.
Historique des frameworks JAVA EE WEB.
Avant l'arrivée de JSF, le marché des frameworks JAVA WEB était dominé par le produit Struts qui
est un logiciel libre. Struts a eu beaucoup de succès dans la première moitié des années 2000. Mais
d'autres produits étaient concurrents comme Tapestry ou Echo. Mais à partir de 2004, c'est à dire de
la sortie de la version 1.5 de JAVA qui apporte le système des annotations, l'offre change et de
nombreux projets voient le jour. Comme par exemple Spring MVC, Stripes et Wicket. Aujourd'hui
d'autres frameworks JAVA WEB sont sur le marché comme Play et Vaadin.
Paradigme du cadriciel JSF.
Une application développée avec JSF repose sur des composants de type page qui agrègent des
sorte de widgets appelés UIComponents. Et sur des classes JAVA annotées pour en faire des
composants ManagedBeans dont le cycle de vie est pris en charge par le framework.
Une page JSF peut correspondre à un ou plusieurs ManagedBeans. Chaque classe ManagedBean
doit respecter le standard JavaBean. C'est à dire posséder un constructeur sans argument et une
méthode get et set par donnée membre qui correspond à la donnée d'un UIComponent présent dans
la page JSF. Il s'agit d'un mapping entre les UIComponents de la page JSF et les données membres
du ou des ManagedBeans qui lui correspondent.
Si la fonction de l'UIComponent est de présenter de l'information c'est la méthode get de la donnée
2/7 Composants Logiciels JJLC
<<page JSF>>
<h:inputText value=''#{nom.donnee}''/>
<h:outputText value=''#{nom.donnee}''/>
<<classe ManagedBean>>
private String donnee ;
public void setDonnee(String donnee) {...}
public String getDonnee() {...}
mapping
Nom symbolique du ManagedBean

membre qui lui correspond dans le ManagedBean qui est invoquée. Si la fonction de
l'UIComponent est d'obtenir de l'information de la part de l'utilisateur, c'est la méthode set de la
donnée membre qui lui correspond dans le ManagedBean qui est invoquée.
Le cœur du cadriciel ou framework représenté par l'implémentation de référence Mojarra est
composé de plusieurs parties. Il y a celles qui sont utilisées côté page : une pour représenter les
artéfacts HTML et l'autre pour l'implémentation des comportements événementiels dans une page
WEB.
Il y a celle qui est utilisée côté application et qui implémente la gestion du cycle de vie des
ManagedBeans et qui prend en charge le contrôle des interactions dont le contrôleur principal est
la SERVLET qui a pour nom FacesServlet et qui doit être déclarée dans le descripteur de
déploiement de l'application, le fichier web.xml.
Car une application JSF est d'abord une application JAVA EE WEB. C'est à dire que l'application
doit être empaquetée dans une archive WAR (Web Application Resource) et respecter la structure de
ce type d'archive.
/ressources statiques
/pages JSF
/WEB-INF/web.xml
/faces-config.xml [optionnel]
/classes/ classes JAVA et ManagedBeans
/lib/ librairies nécessaires à l'application dont le framework JSF
Ce type d'application ne peut s'exécuter qu'au sein d'un serveur JAVA EE. Le profil WEB est
suffisant. Par exemple le serveur JAVA EE TOMCAT de la fondation APACHE. Mais ce type
d'application peut être également déployée dans les serveurs avec profil complet (full profile)
comme WEBSPHERE, JBOSS ou GLASSFISCH. Ceux-ci intègrent le framework JSF nativement.
Navigation entre les pages JSF.
La navigation entre les pages JSF correspond à une partie de la logique applicative. Elle implémente
le dialogue entre l'utilisateur et l'application.
La navigation peut être statique. C'est à dire que l'action sur un composant UIComponent de type
événementiel déclenche l'action de charger une autre page JSF. Le système de nommage repose sur
le nom de la page suivante, plus précisément son radical, c'est à dire son nom sans le suffixe.
La navigation peut-être dynamique et alors dépendre de l'exécution d'une méthode. Une méthode
dans un ManagedBean ou dans une classe écouteur (Listener). Il y a deux façons d'implémenter un
écouteur. Soit dans un ManagedBean soit dans une classe qui implémente l'interface ActionListener.
3/7 Composants Logiciels JJLC
Page JSF
action=''page2''
Autre page JSF
page1.xhtml page2.xhtml
navigation

La méthode du ManagedBean est directement appelée à partir de la page JSF. Peu importe la
logique applicative de la méthode, celle-ci doit retourner une chaîne de caractères qui correspond au
radical du nom de la page JSF suivante dans la logique de navigation.
La méthode peut aussi implémenter une ou plusieurs conditions qui selon leur véracité peut
retourner un nom de page JSF différent. Réalisant ainsi une navigation plus complexe.
L'autre solution est de mettre en œuvre un système événementiel à l'aide d'une classe écouteur qui
implémente l'interface ActionListener et sa méthode processAction(ActionEvent evenement). Dans
cette méthode, il est possible via l'interface de programmation (API) de JSF d'obtenir le contexte
4/7 Composants Logiciels JJLC
Page JSF
action=''#{nom.méthode}''
Autre page JSF
page1.xhtml page2.xhtml
<<classe ManagedBean>>
public String methode() {
...logique de la méthode...
return ''page2'' ;
}
navigation
Page JSF
action=''#{nom.méthode}''
Autre page JSF
page1.xhtml page2.xhtml
<<classe ManagedBean>>
public String methode() {
...logique de la méthode...
if(condition)
return ''page2'' ;
else return ''page3'' ;
}
navigation
Autre page JSF
page3.xhtml

courant et ainsi d'avoir accès à l'état des composants associés à la requête qui a déclenché l'appel de
la méthode processAction.
Il est possible également de définir la navigation dans la méthode événementielle à l'aide d'un objet
de type NavigationHandler et plus dans la page comme dans l'exemple ci-dessus.
Mapping des données entre composant page et composant ManagedBean.
Une page JSF peut correspondre à un ou à plusieurs ManagedBean. Le système de nommage des
composants ManagedBean repose par défaut sur le nom de la classe en minuscule ou sur le nom
précisé par l'attribut name de l'annotation @ManagedBean.
@ManagedBean @ManagedBean(name=''comp'')
@RequestScoped @RequestScoped
public class UnComposant { public class UnAutreComposant {
private String unedonnee; private int uneautredonnee;
... ...
Dans l'exemple ci-dessus, le nom du composant dans le cycle de vie JSF de la classe de gauche est
uncomposant. Celui de la classe de droite est comp.
La correspondance (mapping) dans une page JSF se réalise par l'écriture suivante :
''#{nomDuManagedBean.nomDeLaDonnée}''
Ainsi une page JSF qui est liée au ManagedBean UnComposant doit nommer la donnée membre de
cette façon :
''#{uncomposant.unedonnee}''
et de cette façon avec le composant UnAutreComposant :
''#{comp.uneautredonnee}''
5/7 Composants Logiciels JJLC
Page JSF
action=''page2''
actionListener type=''#{nom}''
Autre page JSF
page1.xhtml page2.xhtml
<<classe implémentant l'interface ActionListener>>
public void processAction(ActionEvent event) {
...logique de la méthode...
}
navigation