Introduction à JSF 2.0 (Java Server...

Introduction à JSF 2.0(Java Server Faces)

Université de Nice - Sophia AntipolisRichard Grin

Version 0.3.2 – 10/7/11Adaptation / tri sélectif : Michel Buffa

21/10/99 Richard Grin JSF - page 2

Plan (1)

� Présentation� Cycle de vie� Java EE 6� Une application Web� Rappels sur HTTP� Page JSF� Fichiers de configuration� Implémentations de JSF (librairies JSF)� Code d’une page JSF


Plan (2)

� Langage EL� Composants standards� Navigation� Portées (requête, session,…)� Beans� Utilisation des EJB� Ajax

Remarque

� Ce support est une introduction à JSF 2.0 utilisé dans un cadre Java EE 6, avec un serveur d’applications du type de Glassfish, et CDI (Contexts and Dependency Injection)



Présentation


Utilité de JSF

� Créer des pages Web dynamiques� Par exemple, une page Web qui est construite à

partir de données enregistrées dans une base de données

� Une grande partie de la programmation liée à la validation des données saisies par l’utilisateur et de leur passage au code de l’application est automatisée ou grandement facilitée

� Ajax sans programmation

JSF

� Framework MVC qui reprend le modèle des interfaces utilisateurs locales (comme Swing)

� Le modèle est représenté par des classes Java, les Java beans, sur le serveur

� Les vues sont représentées par des composants Java sur le serveur, transformées en pages HTML sur le client

� Le contrôleur est un servlet qui intercepte les requêtes HTTP liées aux applications JSF et qui organise les traitements JSF (implicite)


Autres possibilités Java

� D’autres solutions que JSF peuvent être utilisées pour créer des pages Web dynamiques :

� JSPs (aujourd’hui officiellement plus conseillées)� Utilisation de bibliothèques javascript / HTML5 /

Servlets ou Web Services REST� GWT (Google Web Tollkit)� JRuby on rail� Etc



Autres solutions hors Java

� PHP� Ruby on Rails� Python / Pyjama etc (ROR en Python)� ASP (Microsoft)� ColdFusion (Macromedia)� Flash – Flex ??**?? (avenir très sombre ?)

Services rendus par JSF (1/2)

� Architecture MVC pour séparer l’interface utilisateur, la couche de persistance et les processus métier, utilisant la notion d’événement

� Conversion des données (tout est texte dans l’interface utilisateur)

� Validation des données (par exemple, des champs de formulaires requis)

� Automatisation de l’affichage des messages d’erreur en cas de problèmes de conversion ou de validation


Services rendus par JSF (2/2)

� Internationalisation� Support d’Ajax sans programmation

(communication en arrière-plan et mise à jour partielle de l’interface utilisateur)

� Fournit des composants standards simples pour l’interface utilisateur

� Possible d’ajouter ses propres composants� Adaptable à d’autres langages de balise que

HTML (WML par exemple pour les téléphones portables)


Standards

� JSF 2.0 est intégré dans Java EE 6� JSF 2.0 s’appuie sur les standards suivants :

n Servlet 2.5 -> JSF et les Servlets ça marche bien !n Java SE 5.0n Java EE 5.0n JSTL 1.1 -> ATTENTION PAS CONSEILLE !!!

� JSF 2.0 peut (c’est conseillé) utiliser CDI (Contexts and Dependency Injection)n Annotations @EJB, @Inject etc.



Le cycle de vie

� Pour bien comprendre JSF il est indispensable de bien comprendre tout le processus qui se déroule entre le remplissage d’un formulaire par l’utilisateur et la réponse du serveur sous la forme de l’affichage d’une nouvelle page



Le servlet « Faces »

� Toutes les requêtes vers des pages « JSF » sont interceptées par un servlet défini dans le fichier web.xml de l’application Web

� <servlet><servlet-name>Faces Servlet</servlet-name><servlet-class>

javax.faces.webapp.FacesServlet</servlet-class><load-on-startup>1</load-on-startup>

</servlet>


URL des pages JSF

� Les pages JSF sont traitées par le servlet parce que le fichier web.xml contient une configuration telle que celle-ci :

� <servlet-mapping><servlet-name>Faces Servlet</servlet-name><url-pattern >/faces/* </url-pattern>

</servlet-mapping>

Le pattern est souvent aussi de la forme *.faces (les pages dont l’URL se termine par .faces sont considérées comme des pages JSF)


Codage - décodage

� Les pages HTML renvoyées par une application JSF sont représentées par un arbre de composants Java

� L’encodage est la génération d’une page HTML à partir de l’arbre des composants

� Le décodage est l’utilisation des valeurs renvoyées par un POST HTML pour donner des valeurs aux variables d’instance des composants Java, et le lancement des actions associées aux « UICommand » JSF (boutons ou liens)


Cycle de vie

� Le codage/décodage fait partie du cycle de vie des pages JSF

� Le cycle de vie est composé de 6 phases� Ces phases sont gérées par le servlet « Faces »

qui est activé lorsque qu’une requête demande une page JSF (correspond au pattern indiqué dans le fichier web.xml ; le plus souvent /faces/* ou *.faces)

Demande page HTML

� Etudions tout d’abord le cas simple d’une requête d’un client qui demande l’affichage d’une page JSF



La vue� Cette requête HTTP correspond à une page JSF

(par exemple *.faces) et est donc interceptée par le servlet Faces

� La page HTML correspondant à la page JSF doit être affichée à la suite de cette requête HTTP

� La page HTML qui sera affichée est représentée sur le serveur par une « vue »

� Cette vue va être construite sur le serveur et transformée sur le serveur en une page HTML qui sera envoyée au client


Contenu de la vue� Cette vue est un arbre dont les éléments sont des

composants JSF (composants Java) qui sont sur le serveur (des instances de classes qui héritent de UIComponent)

� Sa racine est de la classe UIViewRoot

Construction vue et page HTML

� Une vue formée des composants JSF est donc construite sur le serveur (ou restaurée si elle avait déjà été affichée) : phase « Restore View »

� Puisqu’il n’y a pas de données ou d’événements à traiter, la vue est immédiatement rendue : le code HTML est construit à partir des composants de la vue et envoyé au client : phase « RenderResponse »


Traitement d’un formulaire

� Nous allons cette fois-ci partir d’une requête HTTP générée à partir d’une page HTML qui contient un formulaire (page construite à partir d’une page JSF)

� L’utilisateur a saisi des valeurs dans ce formulaire� Ces valeurs sont passées comme des paramètres

de la requête HTTP ; par exemple, http://machine/page.xhtml?nom=bibi&prenom=bob si la requête est une requête GET, ou dans l’entité d’un POST



Phase de restauration de la vue� La vue qui correspond à la page qui contient le

formulaire est restaurée (phase « Restore View »)� Tous les composants reçoivent la valeur qu’ils

avaient avant les nouvelles saisies de l’utilisateur


Phase d’application des paramètres

� Tous les composants Java de l’arbre des composants reçoivent les valeurs qui les concernent dans les paramètres de la requête HTTP : phase « Apply Request Values »

� Par exemple, si le composant texte d’un formulaire contient un nom, le composant Java associé conserve ce nom dans une variable

� En fait, chaque composant de la vue récupère ses propres paramètres dans la requête HTTP


Phase de validation

� Toutes les validations des données traitées à l’étape précédentes sont exécutées

� Les données sont converties dans le bon type Java

� Si une validation échoue, la main est donnée à la phase de rendu de la réponse


Phase de validation

� Comment c’est fait : chaque composant valide et convertit les données qu’il contient

� Si un composant détecte une valeur non valable, il met sa propriété « valid » à false et il met un message d’erreur dans la file d’attente des messages (ils seront affichés lors de la phase de rendu « render response ») et les phases suivantes sont sautées


Phase de mise à jour du modèle

� Si les données ont été validées, elles sont mises dans les variables d’instance des Java beans associés aux composants de l’arbre des composants


Phase d’invocation de l’application

� Les actions associées aux boutons ou aux liens sont exécutées

� Le plus souvent le lancement des processus métier se fait par ces actions

� La valeur de retour de ces actions va déterminer la prochaine page à afficher (navigation)


Phase de rendu de la réponse

� La page déterminée par la navigation est encodée en HTML et envoyée vers le client HTTP

Sauter des phases� Il est quelquefois indispensable de sauter des

phases du cycle de vie� Par exemple, si l’utilisateur clique sur un bouton

d’annulation, on ne veut pas que la validation des champs de saisie soit effectuée, ni que les valeurs actuelles soient mises dans le modèle

� Autre exemple : si on génère un fichier PDF à renvoyer à l’utilisateur et qu’on l’envoie à l’utilisateur directement sur le flot de sortie de la réponse HTTP, on ne veut pas que la phase de rendu habituelle soit exécutée


immediate=true sur un UICommand

� Cet attribut peut être ajouté à un bouton ou à un lien (<h:commandButton>, <h:commandLink>, <h:button> et <h:link>) pour faire passer directement (immédiatement) de la phase « Applyrequest values » à la phase « InvokeApplication » (en sautant donc les phases de validation et de mise à jour du modèle)

� Exemple : un bouton d’annulation d’un formulaire


immediate=true sur un EditableValueHolder

� Cet attribut peut être ajouté à un champ de saisie, une liste déroulante ou des boîte à cocher pour déclencher immédiatement la validation et la conversion de la valeur qu’il contient, avant la validation et la conversion des autres composants de la page

� Utile pour effectuer des modifications sur l’interface utilisateur sans valider toutes les valeurs du formulaire


Exemple� Formulaire qui contient champ de saisie du code

postal et un champ de saisie de la ville� Lorsque le code postal est saisi, un

ValueChangeListener met automatiquement à jour la ville :<h:inputText valueChangeListener="#{…}" ...

onChange = "this.form.submit()" />

� La soumission du formulaire déclenchée par la modification du code postal ne doit pas lancer la validation de tous les composants du formulaire qui ne sont peut-être pas encore saisis


Une application Web


Etapes du développement

� Ecrire le code des pages JSF et des backingbeans

� (Tester en local en déployant sur un container Web)

� Déployer sur le container Web final� Taper l’adresse de l’application pour tester


Structures des fichiers


Fichier de distribution

� L’application doit être distribuée sous la forme d’un fichier war (fichier de format jar)

� Elle peut être une partie d’un projet de type entreprise, dans ce cas l’application est encore un .war mais contenu dans le .ear du projet global (le .ear contient la partie web dans le .war, la partie EJB dans un ou plusieurs .jar)


Rappels sur HTTP


Requête HTTP

� Le protocole HTTP permet à un client HTTP d’envoyer plusieurs types de requêtes à un serveur

� Les 2 types de base principaux sont les types GET et POST

� GET permet au client de demander une page HTML

� POST permet au client de passer des données au serveur


Réponse du serveur HTTP

� En réponse à une requête d’un client HTTP, un serveur HTTP renvoie au client une réponse


Format d’une requête� La première ligne contient le type de la requête

(GET par exemple), suivi de l’URI qui désigne le destinataire de la requête, suivi du numéro de la version HTTP utilisée

� Ensuite peuvent venir des lignes facultatives (en-têtes) pour indiquer la configuration du client ou des formats de documents acceptés en réponse

� En dernier la requête peut contenir une « entité » composée de données qui pourront être utilisées par le serveur (essentiellement réservé à la requête POST) ; ligne vide avant l’entité


Format d’une réponse

� Une première ligne d’état qui contient la version HTTP utilisée, le code d’état (nombre ; par exemple, 200 indique que tout s’est bien passé) et la description du code (« OK » pour 200)

� Viennent ensuite des lignes d’en-têtes (comme pour la requête du client)

� Finalement, le corps de la réponse est envoyé ; il peut s’agir du contenu d’un fichier HTML ou d’un contenu généré par un programme du serveur


GET

� La fonctionnalité de base de HTTP est de permettre à un navigateur (client HTTP) de récupérer et d’afficher une page Web

� Pour cela le client envoie une requête GET au serveur

� Cette requête contient l’URL de la page Web avec, éventuellement, des paramètres (couples clé-valeur)

� La réponse contient le plus souvent un corps qui est le code d’une page HTML


Exemple de requête GET

GET page.html?nom=Toto&Prenom=Pierre HTTP/1.1

Accept: */*

Host: www.unice.fr

User-Agent: Generic


POST

� Certaines pages Web contiennent des questionnaires remplis par l’utilisateur du navigateur

� Lorsque l’utilisateur clique sur le bouton « Submit », les données qu’il a tapées sont envoyées au serveur par une requête POST

� Cette requête contient l’URI du code qui va traiter les données, ainsi que les données

� La réponse du serveur contient le code de la prochaine page à afficher par le navigateur


Exemple de POST

POST /appl/client.xhtml HTTP/1.1Accept: */*Host: www.unice.fr

nom=TotoPrenom=Pierre


Formulaires HTML

� Une page HTML peut contenir un formulaire (<FORM>)

� Lorsque ce formulaire est soumis au serveur (bouton de type « submit »), les données entrées dans le formulaire sont transmises au serveur par une requête POST ou une requête GET

� Avec GET, les valeurs saisies sont intégrées à l’URI ; avec POST elles sont mises dans l’entité

� C’est l’attribut name des balises qui donne le nom des paramètres de la requête


Page JSF


� Les pages JSF contiennent des balises qui décrivent les composants qui représenteront la page sur le serveur



Une page JSF

� Code XHTML� Contient des parties en EL : #{…}� Utilise souvent une (ou plusieurs) bibliothèque de

composants JSF� Sera traduite en XHTML « pur » pour être envoyée au

client Web

Architecture des applications JSF



JSF, servlets et beans

� Dans l’architecture des applications qui utilisent JSF, on trouve aussi des servlets et des beans

� Les servlets et les beans s’occupent principalement des traitements métier et des accès aux données

� Les pages JSF sont utilisées pour l’interface avec l’utilisateur

Répartition des tâches

� Les pages JSF ne contiennent pas de traitements (pas de code Java ou autre code comme dans les pages JSP, « ancien langage » de JSF pour créer les pages affichées à l’utilisateur)

� Les traitements liés directement à l’interface utilisateur sont écrits dans les backing beans

� Ces backing beans font appels à des EJB ou des classes Java ordinaire pour effectuer les traitements qui ne sont pas liés directement à l’interface utilisateur

� Note : on peut très bien faire des pages JSF, du EL et des Servlets… mais c’est considéré « bas nioveau »

� Attention : pas de JSTL !!! 21/10/99 Richard Grin JSF - page 64

Répartition des tâches (2)

� Les EJB sont chargés de traitements métier et des accès aux bases de données

� Les accès aux bases de données utilisent JPA et des classes entités


Beans

� 2 types principaux de beans :n EJB (essentiellement des beans sessions) liés

aux processus métiern « Backing beans » associés aux pages JSF et

donc à l’interface utilisateur qui font la liaison entre les composants JSF de l’interface, les valeurs affichées ou saisies dans les pages JSF et le code Java qui effectue les traitements métier


Backing bean

� Souvent, mais pas obligatoirement, un backingbean par page JSF

� Voir support de cours sur les Backing Beansn Variables pour les propriétés,n Variable pour stocker des résultats de traitement,n Des méthodes get/set pour les propriétés,n Des méthodes de traitement (qu’on appelle

« command handlers »,n Des écouteurs d’évènements…


EJB

� Un backing bean fournit du code Java pour l’interface graphique

� Lorsqu’un processus métier doit être déclenché, le backing bean cède la main à un EJB

� Un EJB est totalement indépendant de l’interface graphique ; il exécute les processus métier ou s’occupe de la persistance des données

� Les entités JPA 2 sont utilisées par les EJB pour la persistance des données



Container pour les JSF

� Pour qu’il sache traiter les pages JSF, le serveur Web doit disposer d’un container pour ces pages

� On peut utiliser pour cela un serveur d’applications du type de Glassfish, JBoss, WebSphere, WebLogic, OAS..

� Tomcat (projet Apache) est une solution plus légère pour traiter les pages JSFn Mais attention, Tomcat n’est PAS un serveur d’applications,n Pas d’applications distribuées, pas de transactions distribuées, etcn Ne contient pas toutes les bibliothèques J2EE par défaut


Paquetage et classes principales

� Les paquetages javax.servlet, javax.serlet.http, javax.servlet.jsp etc. ne sont pas fournis avec la distribution standard de Java (SDK)

� Ils sont dans la distribution « entreprise » (qui est installée avec la version de netbeans qu’on utilise.

� On peut aussi les récupérer à part pour les utiliser avec la distribution standard ; c'est le cas si on décide d’utiliser Tomcat.


Fichiers de configuration

Les différents fichiers

� WEB-INF/web.xml fichier global de configuration d’une application Web Java

� WEB-INF/faces-config.xml : configuration de la partie JSF de l’application, par exemple pour indiquer la navigation entre les pages ou pour déclarer les beans utilisés par les pages ; plus indispensable avec JSF 2.0 grâce aux annotations Java


Annotations et fichier faces-config.xml

� JSF 2.0 a développé l’emploi des annotations des classes pour configurer son fonctionnement

� Le fichier XML l’emporte sur les annotations, ce qui permet de changer la configuration même si on n’a pas le code source (ou d’éviter de recompiler si on a le code source)


Les différents fichiers (2)

� Fichier WEB-INF/beans.xml, indispensable si CDI est utilisé ; il semble qu’un fichier beans.xml vide suffise à déclencher l’utilisation de CDI (attention, si ce fichier n’existe pas, CDI n’est pas utilisé, sans aucun message d’avertissement, et donc les @Inject ne fonctionnent pas)

� Fichiers de description des balises (tags) personnalisées dans le cas où des balises personnalisée sont utilisées (voir la section sur les composants personnalisés)n Ex : vous faites vos composants, un lecteur vidéo par exemple.



Implémentations de JSF –librairies JSF

Implémentations

� Implémentation de référence de JSF� Librairies de composants


Implémentation de référence

� Projet Mojarra� Fournit les composants de base et avec des

fonctionnalités minimales� De nombreuses librairies fournissent d’autres

composants ou enrichissent les fonctionnalités des composants de l’implémentation de référence


Librairies de composants

� L’idéal serait que toutes les librairies de composants soient compatibles entre elles, ce qui permettrait de choisir ses composants dans plusieurs librairies

� Dans la réalité ça n’est pas toujours le cas et il vaut mieux bien choisir la librairie et s’y tenir

� Principales librairies : PrimeFaces, RichFaces, OpenFaces, Icefaces, ADF Faces



Code d’une page JSF

Structure globale d’une page

� Fichier xhtml� tag html qui précise les namespaces utilisés� En-tête de la page (h:header) qui permet

d’indiquer les css, les include javascript, etc� Le corps de la page (du XHTML et des tags JSF)� Voir aussi les templates dans la une autre partie

de ce cours.


Commentaires (1/2)

� Par défaut les commentaires HTML ( ) ne fonctionnent pas pour JSF

� Une solution est de configurer l’application pour que ces commentaires soient pris en compte par Facelets en ajoutant ceci dans web.xml :<context-param>

<param-name>facelets.SKIP_COMMENTS</param-name> <param-value>true</param-value>

</context-param>

Commentaires (2/2)

� Cependant, dans certains cas, des information mises dans des commentaires HTML peuvent être utilisés par l’application

� Le plus sûr est donc d’entourer ce que l’on veut commenter par le tag <ui:remove>

� On peut mettre ce tag dans tous les emplacements où on pourrait mettre un composant JSF



Langage EL(Expression Language)

Utilité

� Sert à relier des propriétés ou des méthodes de beans avec des valeurs de pages JSF

� Une expression EL est entourée par #{…}� Exemple :

<h:inputText value="#{utilisateur.nom}"/>

lie la valeur du champ de saisie de texte avec la propriété « nom » du bean « utilisateur »



Composants standards

Librairies de balises

� Plusieurs librairies de balises peuvent être utilisées dans une page JSF (avec Facelets) :n JSF Facelets, de préfixe uin JSF HTML, de préfixe hn JSF core tag, de préfixe fn JSTL core tag (version 1.1), de préfixe cn JSTL functions tag (version 1.1), de préfixe fnn Eviter JSTL !

� Ces préfixes correspondent à des espaces de noms XML (URL à voir dans la documentation)


� Il est impossible dans cette introduction de passer en revue toutes les balises standards offertes par Facelets

� De nombreux sites Web en donnent des exemples

� Documentation pour ces balises : http://download.oracle.com/javaee/6/javaserverfaces/2.0/docs/pdldocs/facelets/

� Dans cette section nous donnerons quelques conseils pour débuter


Quelques références

� Le tutoriel Java EE 6 d’Oracle est un bon site pour débuter : http://download.oracle.com/javaee/6/tutorial/doc/bnarf.html


Types de composants

� 4 grands types :n Ceux qui contiennent une valeur (ValueHolder

ou EditableValueHolder) ; un label ou un champ de saisie par exemple

n Ceux qui proposent un choix à l’utilisateur (liste déroulante, boîtes à cocher, boutons radio,…)

n Ceux qui lancent une action (ActionSource2) ; un bouton par exemple

n Ceux qui correspondent à une structure itérative ; une datatable par exemple


� Nous allons étudier un exemple de chaque type pour en illustrer les particularités

� Reportez-vous à la documentation de JSF ou de la librairie de composants que vous utilisez pour en savoir plus


Composants pour du texte

� Champ texte avec <h:inputText> (1 ligne)� Saisie des mots de passe avec <h:inputSecret>� Zone de texte de plusieurs lignes avec

<h:inputTextarea>


Image tutoriel Java EE 6 d’Oracle

Les listes

� Il y a plusieurs composants JSF standards qui permettent de proposer un choix (ou plusieurs) parmi une liste de valeurs

� Tous les composants sont bâtis sur des classes Java communes mais se présentent différemment à l’utilisateur


Listes à choix unique� Boutons radios avec <h:selectOneRadio>� Liste déroulante avec <h:selectOneMenu>� Liste non déroulante avec <h:selectOneListbox>



Listes à choix multiple

� Boîtes à cocher avec <h:selectManyCheckbox>� Liste déroulante avec <h:selectManyMenu>� Liste non déroulante avec <h:selectManyListbox>



Les listes - Exemple<h:selectOneListbox value="#{bean.choix}">

<f:selectItem itemLabel="choix"

itemValue="#{bean.option}" />

<f:selectItem itemLabel="autre choix"

itemValue="false" />

<f:selectItems value="#{bean.options}"/>

</h:selectOneListbox>


Ce qui est désigné par f:selectItem et f:selectItems sera affiché dans la liste. Le choix fait par l’utilisateur parmi toutes ces valeurs, est rangé dans bean.choix (attribut value de selectOneListBox )

Les entrées de la liste qui correspondent à l’attribut value sont présélectionnées dans la liste

Classe SelecItem

� Paquetage javax.faces.model� Donne un label, une valeur et d’autres propriétés

d’une liste de GUI� Utilisée pour la valeur (attribut value) des tags

<f:selectItem> et <f:selectItems>


<f:selecItems>

� Son attribut value peut désigner un tableau, une collection ou une map

� Le plus souvent, on part d’une liste d’éléments et on la transforme en tableau ou collection de SelectItem

� Le transparent suivant donne un schéma de code pour une telle transformation (souvent fourni sous la forme d’une méthode static utilitaire)


Schéma de code pour <f:selecItems>

public static SelectItem[]

getSelectItems(List<?> entities) {

SelectItem[] items = new SelectItem[size];

for (Object x : entities) {

items[i++] =

new SelectItem(x, x.toString());

}

return items;

}


Autre façon de faire

� Pour éviter la complication de la transformation en SelectItem , on peut utiliser les attributs var , itemValue et itemLabel

� Exemple :<f:selectItems

value="#{ecoleController.personnes} "var="personne" itemValue="#{personne.id}"itemLabel="#{personne.nom}"/>


La variable «personne » contient un élément de la liste désignée par value

Chausse-trappes avec les listes

� Quelques chausse-trappes que l’on peut rencontrer avec les listes déroulantes sont exposées dans les transparents suivants

� En particulier avec les convertisseurs et les validateurs qui seront étudiés en détails dans la 2ème partie de ce cours sur JSF


Conversion pour les listes déroulantes

� Comment se fait la conversion entre les éléments d’une liste et ce qui est affiché ?

� Par exemple, une liste d’écoles et ce qui est affiché ?

� Il faut bien comprendre que le composant JSF va être transformé en élément(s) HTML et que toutes les valeurs vont être transformées en String ; en retour, une valeur choisie par l’utilisateur sera une String qu’il faudra éventuellement convertir en un autre type


Convertisseur

� Si le type T des éléments à choisir n’est pas String (ça peut, par exemple, être des pays de la classe Pays), il faut un convertisseur pour passer du type T à String (pour le passage en HTML) et vis-versa (pour le rangement du choix sous la forme d’une instance du type T)

� On aura un message d’erreur si on veut mettre une 1ère entrée du type « Choisissez un pays » car cette première entrée n’est pas du type Tn Solution : ne pas mettre cette première ligne !


Validation d’un choix dans une liste

� JSF vérifie que le choix qui est envoyé au serveur est bien un des choix proposés à l’utilisateur

� Ça implique que les choix proposés soient connus par JSF au moment de la validation

� Si les choix dépendent d’une propriété d’un backing bean (par exemple, un pays pour une liste de villes d’un certain pays), il faut donner la bonne portée au bean pour que les choix puissent être calculés correctement au moment de la validation (View ou Session par exemple)


<h:datatable>

� Très utilisé pour représenter les données d’une base de données : chaque ligne de la table correspond à une ligne d’une table

� Sera affiché comme une table HTML


Modèle de données

� Les données affichées sont représentées par un model : javax.faces.model.DataModel

� Souvent on n’utilise pas directement le modèle ; on fournit un tableau, une liste ou un ResultSet à l’attribut value de <h:datatable> ; en interne une classe fille de DataModel enveloppera les données fournies

� Quelquefois il faut expliciter l’utilisation de DataModel dans le backing bean de la page pour avoir plus de facilités de manipulation des données


DataModel

� Contient des méthodes pour récupérer les numéros des lignes, la valeur de la ligne « en cours » (un Object), gérer les écouteurs de la table


Exemple

<h:datatable value="#{clientBean.all}"

var="client">

<h:column>

<f:facet name=header>Nom</f:facet>

#{client.nom}

</h:column>

...

</datatable>


<ui:repeat >

� Permet de répéter un affichage sur une liste d’objets

� Exemple :<ul>

<ui:repeat value="#{bean.clients}" var="item">

<li>#{item.nom}</li></ui:repeat>

</ul>



Navigation


Handler de navigation� La navigation entre les pages indique quelle page est

affichée quand l’utilisateur clique sur un bouton pour soumettre un formulaire ou quand il clique sur un lien

� Cette navigation est déléguée au « handler de navigation »� La navigation peut être définie par des règles dans le fichier

de configuration faces-config.xml ou par des valeurs écrites dans le code Javan En général on s’en passe mais si on veut faire une navigation

«logique » on peut utiliser les wizards de netbeans


Navigation statique et dynamique� La navigation peut être statique : définie « en

dur » au moment de l’écriture de l’application� La navigation peut aussi être dynamique : définie

au moment de l’exécution par l’état de l’application (en fait par la valeur retournée par une méthode)


Dans les pages JSF

� Dans les pages JSF on indique la valeur ou la méthode associée à un bouton qui déterminera la navigation

� Avec une valeur :<h:commandButton value= " Texte du bouton "

action="valeur" />

� Ou avec une méthode (qui retourne une valeur) :<h:commandButton value= " Texte du bouton "

action="#{nomBean.nomMethode}" />

Modèle de navigation JSF,Le modèle GET - PRG


� Par défaut, JSF travaille avec des requêtes POST� Depuis JSF 2.0 il est plus simple de travailler

avec des requêtes GET, ce qui facilite l’utilisation de l’historique et marque-pages (bookmarks) des navigateurs et évite des doubles validations de formulaire non voulues par l’utilisateur


Utiliser GET

� 2 composants de JSF 2.0 permettent de générer des requêtes GET : <h:button> et <h:link>


Le problème avec POST� Avec une requête POST envoyée pour soumettre

un formulairen le refresh de la page affichée (ou un retour en

arrière) après un POST soumet à nouveau le formulaire ; le navigateur prévient l’utilisateur en affichant une fenêtre popup inquiétante et difficile à comprendre pour l’utilisateur

n l’adresse de la page affichée après le POST est la même que celle du formulaire (donc pas possible de faire réafficher cette page en utilisant l’historique du navigateur)


La raison du problème

� C’est le servlet qui intercepte les requêtes attachées aux pages JSF qui redirige vers la page désignée par le modèle de navigation JSF

� Le navigateur n’a pas connaissance de cette direction et pense être toujours dans la page qui contient le formulaire qui a été soumis

� On avait déjà le problème l’année dernière avec les HTTP forwarder dans les Servlets, mais cela ne vous a pas troublé outre mesure ;-)


Les conséquences du problème

� Le navigateur est en retard d’une page pour afficher l’URL de la page en cours

� Il ne garde donc pas la bonne adresse URL si l’utilisateur veut garder un marque-page

� Le navigateur pense être toujours dans la page qui contient le formulaire après un retour en arrière ou un refresh et il essaie de le soumettre à nouveau (il demande malgré tout une confirmation lors de la soumission multiple d’un formulaire)


La solution : POST, REDIRECT, GET (PRG)

� Le modèle POST– REDIRECT– GET préconise den Ne jamais montrer une page en réponse à un

POSTn Charger les pages uniquement avec des GETn Utiliser la redirection pour passer de POST à

GET


Sans PRG


Cette image et la suivante viennent de Wikipedia

Avec PRG


Problème de PRG

� PRG peut poser un problème lorsque la page vers laquelle l’utilisateur est redirigée (le GET), doit afficher des données manipulées par le formulaire

� C’est le cas, par exemple, lorsque cette page est une page qui confirme l’enregistrement dans une base de données des informations saisies par l’utilisateur dans le formulaire

� En effet, les informations conservées dans la portée de la requête du POST ne sont plus disponibles


Solutions� Une des solutions est de ranger les informations

dans la session plutôt que dans la requête� Cependant cette solution peut conduire à une

session trop encombrée� Une autre solution est de passer les informations

d’une requête à l’autre� JSF 2.0 offre 2 nouvelles possibilités qui facilitent

la tâche du développeur :n la mémoire flashn les paramètres de vue


Paramètres de vue

� Les paramètres d’une vue sont définis par des balises <f:viewParam> incluses dans une balise <f:metadata> (à placer au début, avant les <h:head> et <h:body> ) :<f:metadata>

<f:viewParam name="n1" value="#{bean1.p1}" />

<f:viewParam name="n2" value="#{bean2.p2}" />

<f:metadata>


<f:viewParam>

� L’attribut name désigne le nom d’un paramètre de requête GET

� L’attribut value désigne (par une expression du langage EL) le nom d’une propriété d’un beandans laquelle la valeur du paramètre est rangée

� Important : il est possible d’indiquer une conversion ou une validation à faire sur les paramètres, comme sur les valeurs des composants saisis par l’utilisateur


� Un lien vers une page qui contient des balises <f:viewParam > contiendra tous les paramètres indiqués par les <f:viewParam > s’il contient « includeViewParams =true »

� Exemple :<h:commandButton value=…

action="page2?faces-redirect=true& includeViewParams=true "


Fonctionnement de includeViewParams

1. La page de départ a un URL qui a le paramètre includeViewParams

2. Elle va chercher les <f:viewParam > de la page de destination. Pour chacun, elle ajoute un paramètre à la requête GET en allant chercher la valeur qui est indiquée par l’attribut value du <f:viewParam >

3. A l’arrivée dans la page cible, la valeur du paramètre est mise dans la propriété du beanindiquée par l’attribut value


Fonctionnement de includeViewParams

� Ca revient à faire passer une valeur d’une page à l’autre

� Si la portée du bean est la requête et qu’il y a eu redirection, ça revient plus précisément à faire passer la valeur d’une propriété d’un bean dans un autre bean (de la même classe)


Donner une valeur à un paramètre

� Il y a plusieurs façons de donner une valeur à un paramètre de requête GET ; les voici dans l’ordre de priorité inverse (la dernière façon l’emporte)n Dans la valeur du outcome

<h:link outcome="page?p=4&p2=‘bibi’ " …><h:link outcome="page?p=#{bean.prop + 2} " …>

n Avec les paramètres de vue<h:link outcome="page" includeViewParams="true" …>

n Avec un <f:param><h:link outcome="page" includeViewParams="true" …><f:param name=p value=…/> </h:link>


Exemple ; page2.xhtml

<!DOCTYPE …>

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns=...>

<f:metadata>

<f:viewParam name="param1"

value="#{bean.prop1}"/>

<f:viewParam name="param2" value="#{…}"/>

</f:metadata>

<h:head>…</h:head>

<h:body>

Valeur : #{bean.prop1}


Fonctionnement

� Si page2 est appelé par la requête GET suivantepage2.xhtml?param1=v1&param2=v2la méthode setProp1 du bean est appelée avec l’argument v1 (idem pour param2 et v2)

� Si un paramètre n’apparait pas dans le GET, la valeur du paramètre de requête est null et le setter n’est pas appelé (la propriété du bean n’est donc pas mise à null)


Conserver des adresses utiles

� Outre le fait qu’un refresh ne provoque plus de soumission du formulaire, le modèle PRG permet aussi de permettre de conserver un URL utile dans un marque-page ou dans l’historique

� En effet, l’URL contient les paramètres qui permettront de réafficher les mêmes données à un autre moment

� Sans PRG, les données utiles sont conservées dans l’entité de la requête et pas dans l’URL


preRenderView Listener (1)

� Une situation courante : il est possible de ne mettre en paramètre qu’un identificateur des données qui ont été traitées

� Par exemple, que la clé primaire des données enregistrées dans la base de données

� Avec les procédés précédents on peut faire passer cet identificateur dans la page qui va afficher les données


preRenderView Listener (2)

� Mais ça ne suffit pas ; il faut utiliser une autre nouveauté de JSF 2.0, les listeners« preRenderView » qui permet d’exécuter une action avant l’affichage de la vue

� On peut ainsi aller rechercher (par exemple dans une base de données) les informations identifiées par l’identificateur


Exemple de preRenderView

<f:metadata>

<f:viewParam name="id"

value="#{bean.IdClient}"/>

<f:event type="preRenderView"

listener="#{bean.chargeClient}"/>

</f:metadata>

...

Nom : #{bean.client.nom}

...


Portées


Les différentes portées (scope)

� Application� Session� Requête� Conversation� Vue� Personnalisée (custom)


� Les différentes portée peuvent conserver des objets dans des maps


� Lorsqu’une valeur est référencée dans une page Web, la valeur est d’abord recherchée dans le scope le plus « proche » : requête, vue, session, application, etc


Mettre une valeur dans une portée

� Cours à venir… voir support de cours sur les backing beans (à venir lui aussi)


Mémoire flash� Il est bon de limiter la taille des informations

entreposées dans la session� Cependant la portée « request » peut ne pas

convenir, en particulier s’il y a redirection de la requête (par exemple pour appliquer le modèle POST – REDIRECT – GET)

� La mémoire « flash » peut alors convenir : un objet mis dans la mémoire flash est encore disponible dans la prochaine requête issue de la même session ; il est ensuite effacé automatiquement de la mémoire flash


Utiliser la mémoire flash (page Web)

� Dans une page Web, avec le langage EL (flashest un objet implicite du langage) :#{flash.objet}


Utiliser la mémoire flash (en Java)

� Dans le backing bean par ex : il faut récupérer le contexte externe :ExternalContext ec =

FacesContext.getCurrentInstance().getExternalContext().getFlash();

qui renvoie un objet de la classe Flash (de javax.faces.context ) qui se manipule comme une session (comme une map) dont la clé est une String et la valeur est un Object

� Par exemple,ec.getFlash().put("nom", nom);


Exemple

<h:form>

<h:inputText value=" #{flash.nom} " .../>

...

<h:commandButton value="Enregistrer"action="confirm? faces-redirect=true " />

</form>

Page confirm.xhtml :<h:form>

<h:outputText value=" #{flash.nom} " .../>

...


keep

� Il est possible de garder l’objet pour une requête de plus grâce à la méthode keep de la classe Flash

� #{flash.keep.objet} renvoie l’objet qui a la clé « objet » et garde l’objet pour encore une requête de plus

� Dans le code Java, il faut le faire en 2 étapes : récupérer la valeur et remettre dans le flash pour la prochaine requête en appelant la méthode keepqui ne renvoie rien (void comme type retour).


Backing beans


� Dans la section « Architecture des applications JSF » on a vu que les pages JSF sont épaulées par des backing beans qui apportent la puissance du langage Java pour coder des interactions sophistiquées avec l’utilisateur

� Les possibilités sont infinies� Dans cette section nous allons voir quelques

exemples caractéristiques de l’utilisation des backing beans


Plus de code dans les pages JSF

� Pour ceux qui ont travaillé avec JSP, il faut oublier la mauvaise habitude d’inclure de la programmation dans les pages JSF

� Tout le code (non « métier ») doit maintenant se trouver dans les backing beans (le code métier doit se trouver dans les EJB ou classes Java liées)


EJB


� Pour plus de détails, se référer au cours sur les EJB

� Nous allons voir ici quelques utilisations caractéristiques des EJB par le code des backingbeans


Ajax


Ajax

� Asynchronous Javascript and XML� Permet des échanges entre le client et le serveur

Web sans affichage d’une page entière� Les requêtes envoyées par le client sont lancées

« en arrière-plan » ; l’utilisateur peut continuer à travailler avec la page en cours

� La réponse du serveur à la requête peut ne modifier qu’une partie de la page en cours


<f:ajax>

� Pemet d’ajouter des fonctionnalités « Ajax » au composant JSF dans lequel il est inclus

� Par exemple, un bouton de soumission de formulaire peut envoyer une requête et la réponse du serveur mettra à jour une partie de la page sur laquelle l’utilisateur a continué à travailler


<f:ajax> - les attributs

� event : événement déclencheur de la requête� execute : composants pris en compte pour l’envoi

de la requête (espace séparateur)� render : composants mis à jour au moment de la

réponse du serveur (espace séparateur)


Exemple 1

<h:form>

<h:input value= />

<h:commandButton>

<f:ajax event="click" execute="@form"

listener="#{bean.ajaxListener} "

render="out1 out2" />

</h:commandButton>

<h:input id="out1" …/>

<h:input id="out2" …/>

</h:form>


Exemple 2

<h:form>

<h:input value="#{bean.***" />

<h:selectOneMenu value="#{bean.selected}">

<f:selectItems value="#{bean.items}" />

<f:ajax event="change" execute="@form"

listener="#{bean.ajaxListener}"

render="@form" />

</h:selectOneMenu>

...

</h:form>


Compléments sur les attributs

� Chaque type de composant a un type d’événement par défaut

� Par exemple, valueChange pour les <h:inputText> ou action pour les <h:commandButton>


Compléments sur les attributs

� execute et render doivent indiquer un ou plusieurs identificateurs de composants

� Quelques valeurs particulières : @all, @this (le composant qui englobe <f:ajax> ; défaut pour execute), @form (tous les composants du formulaire), @none (défaut pour render) ; on peut aussi donner une expression EL qui fournit une collection de String (qui désignent des identificateurs) ; expression évaluée durant le rendu de la page


Composants inclus dans <f:ajax>

� <f:ajax> peut aussi encadrer plusieurs composants JSF qui lanceront alors des appels Ajax sur les événements indiqués :<f:ajax …>

<h:panelGrid …><h:inputText …/><h:commandButton …/>

</ panelGrid ….></ ajax >


Conversion


Utilité des converters

� Quand le serveur reçoit une requête POST, les valeurs saisies par l’utilisateur arrivent sous la forme de chaînes de caractères

� Ces chaînes doivent souvent être traduites en objets Java

� Par exemple, si un candidat à une formation a indiqué sa nationalité par une liste déroulante, ce choix doit être traduit en un objet Pays qui sera associé à l’objet Candidat qui représente l’utilisateur


Désigner un convertisseur

� Lorsqu’un composant a besoin d’un convertisseur, on peut le désigner n par une sous-balise <f:converter> en donnant

l’identificateur du convertisseur : <f:converter converterId=xxx>

n par l’attribut converter du composant<h:outputText value=xxx converter=yyy/>

n Par une sous-balise spéciale pour les convertisseurs standards


Convertisseur par défaut

� On verra qu’il est aussi possible d’associer un convertisseur par défaut pour un type

� Ce convertisseur par défaut sera utilisé si aucun convertisseur n’est explicitement désigné

� Une erreur est lancée si aucun convertisseur n’est donnée par son identificateur et qu’aucun convertisseur par défaut n’existe pour le type


Convertisseurs standards

� JSF fournit des convertisseurs pour les types primitifs, pour les dates et pour les classes BigInteger et BigDecimal

� Des balises spéciales sont fournies par JSF pour les convertisseurs standards mais on peut aussi utiliser la balise <f:convert> en donnant l’identificateur du convertisseur standard

� Par exemple, <f:convertDateTime/> est équivalent à <f:convert convertId="javax.faces.DateTime"/>


Exemples

� <inputText value= "#{employe.salaire} "><f:convertNumber type= "currency "/>

</inputText>

� <outputText value= "#{employe.salaire} "><f:convertNumber type= "currency "/>

</outputText>

� <inputText value= "#{employe.dateNaissance} "><f:convertDateTime

pattern= "dd/MM/yyyy "/></inputText>


Convertisseur personnalisé

� Le développeur doit écrire les convertisseurs associés aux types qui ne sont pas pris en charge par les convertisseurs standards de JSF (custom converter)

� Il fautn écrire la classe Java du convertisseurn indiquer quand utiliser le convertisseur


Écrire un convertisseur

� Classe Java qui implémente l’interface Converter (paquetage javax.faces.convert)

� Cette interface contient les 2 méthodesn Object getAsObject(FacesContext,

UIComponent, String) qui transforme une chaîne de caractères en objet

n String getAsString(FacesContext, UIComponent, Object) qui transforme un objet en chaîne de caractères


� Comme pour un validateur, il n’est pas possible d’utiliser @Inject dans un convertisseur

� Mais on peut écrire ce type de code pour utiliser un EJB ou une ressource :try {

ic = new InitialContext();myejb= (MyEJB) ic

.lookup("java:global/xxxx/MyEJB"); } catch (NamingException e) {

…}


Désigner un convertisseur

� Lorsqu’un composant doit utiliser un convertisseur, si aucun convertisseur particulier n’est désigné par son identificateur c’est le convertisseur par défaut du type qui est utilisé

� Pour désigner un convertisseur particulier ou un convertisseur par défaut d’un type, le développeur peut utiliser une annotation ou écrire une configuration dans le fichier faces-config.xml


Annotation @FacesConverter

� L’attribut par défaut donne un identificateur : @FacesConverter("fr.unice.Pays")

� L’attribut forClass indique que le convertisseur est le convertisseur par défaut d’une classe : @FacesConverter(forClass=fr.unice.Pays.class)


Fichier faces-config.xml

� Donne un identificateur à la classe du convertisseur :<converter>

<converter-id>fr.unice.Pays</converter-id><converter-class>fr.unice.PaysConverter</converter-class>

</converter>

� Indique la classe du convertisseur par défaut d’un type :<converter>

<converter-for-class>fr.unice.Pays</converter-for-class> <converter-class>fr.unice.Pays</converter-class>

</converter>


Balise personnalisée pour convertisseur

� Il est possible de créer de nouvelles balises pour avoir des convertisseurs qui ont des attributs comme, par exemple, l’attribut pattern de la balise <f:convertDateTime>

� Pour cela, comme pour toutes les balises personnalisées, il faut écrire un fichier de description de balises (voir section sur les balises et composants personnalisés) ou créer un fichier jar à part


Bibliographie

� Core JSF, 3ème édition mise à jour pour JSF 2.0. David Geary et Cay Horstmann. Prentice Hall.Le meilleur livre pour débuter.

� The Complete Reference JSF 2.0. Ed Burns et Chris Schalk. Quelques compléments intéressants par rapport au livre Core JSF.

� JSF 2.0 Cookbook. Anghel Leonard. Packt Publishing. Descriptions détaillées de quelques recettes pour résoudre des points précis.


Introduction à JSF 2.0 (Java Server...

Documents

Transcript of Introduction à JSF 2.0 (Java Server...