Les JavaServer Faces (JSF), un framework MVC

Nicolas Pietri

Contribution période 2, en date du 06.01.19

Les JavaServer Faces (JSF), un framework MVC

 

Tables des matières

Résumé -2

Introduction -3

Qu’est-ce qu’un Framework  MVC - 4

Frameworks MVC basés sur les requêtes - 4

JSF, framework MVC basé sur les composants – 4

Comparaison entre ces deux Design Pattern- 5

Ecosystème- 5

Versions - 5

JSF- 6

  Son rôle -6

  Architecture-7

  Cycle de vie-8

Références -11

 

 

Résumé

In JAVA EE, there are two families of MVC frameworks. The first ones are based on actions / queries, like Spring. The second category of MVC frameworks qualifies those who base themselves not on queries, but on components, like JSF.

JavaServer Faces (JSF) is a Model,View,Controller (MVC) Web framework based on component for web applications that respect the JAVA EE architecture.

It simplifies the construction of User Interfaces (UI) for server applications that use reusable UI components in a page.

The first goal of JSF is to provide a development environment to build a web-like interface, without having to touch the HTML and JavaScript code. This is achieved by setting up a mapping between the HTML and the objects concerned. JSF is based on the concept of components, comparable to that of Swing, where the state of these components is saved and restored when the request returns.

Through this article, we will attempt to describe in general terms what a JSF is, develop its operating principle, highlight its strengths and limitations, and present a concrete case.

 

Introduction

 

JavaServer Faces est un framework de type MVC, destiné aux applications web respectant l'architecture J2EE.

JSF est une infrastructure MVC basée sur des composants qui repose sur l'API Servlet et fournit des composants via des taglibs qui peuvent être utilisés dans JSP ou toute autre technologie d'affichage basée sur Java telle que Facelets .

Facelets est beaucoup plus adapté à JSF que JSP. Il fournit notamment d'excellentes fonctionnalités de modélisation, telles que des composants composites, tandis que JSP ne propose en principe que la <jsp:include>création de modèles, de sorte que vous êtes obligé de créer des composants personnalisés avec du code Java brut (ce qui est un peu opaque et très fastidieux en JSF) lorsque vous souhaitez remplacer un groupe répété de composants par un seul composant.

Depuis JSF 2.0, JSP est devenu une technologie obsolète en faveur de Facelets.

En tant que structure MVC ( Model-View-Controller ), JSF fournit FacesServlet, le seul contrôleur de requête-réponse . Il prend en charge tous les travaux standard simples et fastidieux de requête / réponse HTTP, tels que la collecte des entrées utilisateur, leur validation / conversion, leur insertion dans des objets de modèle, l'appel d'actions et le rendu de la réponse.

De cette façon, vous vous retrouvez avec une page JSP ou Facelets (XHTML) pour View et une classe JavaBean comme modèle. Les composants JSF sont utilisés pour lier la vue au modèle) et FacesServlet utilisent l’arborescence des composants JSF pour effectuer tout le travail.

 

Qu'est-ce qu'un framework MVC ?

La brique de base de la plate-forme Java EE est la servlet. Tout passe par elle, et même nos pages JSP sont transformées en servlets derrière les rideaux.

Un framework MVC n'est rien d'autre qu'une surcouche à cette technologie de base. En masquant ces rouages les plus basiques, une telle solution facilite le découpage et la gestion du code d'une application. Elle intervient sur le cycle de vie d'une requête dans l'application, et prend en quelque sorte la main sur son cheminement. Voilà pourquoi on qualifie souvent les frameworks MVC de frameworks d'inversion de contrôle, parfois abrégé en IoC.

 

Framework MVC basé sur les requêtes

La première catégorie de frameworks MVC qualifie ceux qui se basent sur les requêtes ; on parle également de frameworks basés sur les actions.

Ici, le développeur travaille toujours de près ou de loin sur la paire requête/réponse. Le gros changement à noter, est la mise en place d'une servlet unique jouant le rôle d'aiguilleur géant (ou Front Controller). Celle-ci se charge de déléguer les actions et traitements au modèle métier en se basant sur l'URL de la requête et sur ses paramètres. Le développeur peut alors travailler directement sur les objets HttpServletRequest et HttpServletResponse bruts dans le modèle, ou bien utiliser le système de mapping fourni par le framework. Ce système permet au développeur de confier au framework les tâches de regroupement, conversion et validation des paramètres de requête, et si nécessaire de mise à jour des valeurs du modèle de données, avant d'invoquer les actions métier. Enfin, il doit toujours écrire lui-même les pages - bien souvent des pages JSP - en charge de créer les réponses à renvoyer au client, et il jouit donc d'une liberté totale sur le rendu HTML/CSS/JS de chaque vue.

Trois grands acteurs existent : Spring, bien souvent couplée à Hibernate pour la persistance des données ; Struct, solution éditée par Apache ; et Stripes.

 

JSF, Framework MVC basé sur les composants

La seconde grande catégorie de frameworks MVC qualifie ceux qui se basent non pas sur les requêtes, mais sur les composants.

JSF appartient à ce Design Pattern et est basé sur la notion de composants, comparable à celle de Swing ou SWT, où l'état d'un composant est enregistré lors du rendu de la page, pour être ensuite restauré au retour de la requête.

À la différence de ceux basés sur les requêtes, les frameworks basés sur les composants découpent logiquement le code en "composants", masquant ainsi le chemin d'une requête au sein de l'application. Ils essaient en quelque sorte d'abstraire les concepts de requête et réponse, et de traiter une application comme une simple collection de composants qui présentent leur propre méthode de rendu et des actions pour effectuer des tâches.

Dans le MVC basé sur les composants, une unique servlet jouant le rôle de Front Controller va elle-même regrouper, convertir et valider les paramètres de requête, et mettre à jour les valeurs du modèle. Le développeur n'a ainsi à se soucier que des actions métier. La façon dont le contrôleur regroupe/convertit/valide/met à jour les valeurs est définie dans un unique endroit, la vue. Puisque c'est impossible à réaliser à l'aide de simple HTML "pur", un langage similaire spécifique est requis pour y parvenir. Dans le cas de JSF, c'est un langage basé sur du XML (XHTML). Vous utilisez du XML pour définir les composants de l'interface utilisateur, qui eux contiennent des informations sur la manière dont le contrôleur doit regrouper/convertir/valider/mettre à jour les valeurs et générer lui-même le rendu HTML.

 

Comparaison entre ces deux Design Pattern

Certains avancent que le plus gros inconvénient de JSF est qu'il n'autorise que peu de contrôle sur le code HTML/CSS/JS généré. Cela ne tient en réalité pas à JSF en lui-même, mais simplement au fait que c'est un framework MVC basé sur les composants, et pas sur les requêtes (actions).

En réalité, c'est très simple : si un haut niveau de contrôle sur le rendu HTML/CSS/JS est votre principale exigence lorsque vous choisissez un framework MVC, alors vous devez regarder du côté des frameworks basés sur les requêtes comme Spring MVC.

Ecosystème de JSF

Au-delà d’être simplement un framework web, JSF offre un écosystème de bibliothèques et extensions UI. Cela signifie que vous pouvez prendre un composant d'interface utilisateur à partir d'une bibliothèque, comme un arbre ou d'une table scrollable, et l'utiliser sur n’importe quelle implémentation du JSF.

Histoires/ Versions des JSF

JSF 1.0 Première version des spécifications de JSF, est sortie le 11 mars 2004.

JSF 2.0 sorti le 28 juin 2009 remplace les précédentes versions et correspond à la première mise à jour majeure des spécifications entrainant de nombreuses modifications, afin d'en faciliter l'utilisation, augmenter les fonctionnalités et les performances. Cette sortie coïncide avec celle de Java EE 6.

JSF 2.3 est la norme d'interface utilisateur désignée pour Java EE 8. La version finale date du 17 avril 2017.

Facelets (spécialement conçu pour JavaServer Faces) a été adopté comme technologie d'affichage officielle pour JSF 2.0. Cela élimine les conflits de cycle de vie qui existaient avec JSP, contraignant les développeurs Java à contourner le problème. Facelets permet de créer facilement des composants / balises à l’aide de balises XML au lieu de code Java, principal grief contre JSF 1.x.

 

JSF, son rôle :

JSF a deux fonctions principales. La première consiste à générer une interface utilisateur, généralement une réponse HTML qui est servie à un navigateur et considérée comme une page Web. Cette interface utilisateur est représentée sur le serveur par un arbre composant. Il y a une correspondance 1 à 1 entre les éléments dans l'arborescence des composants et des éléments de l'interface utilisateur. L'interface d'utilisateur est générée lorsque l'arborescence des composants est codée. Cette séparation entre arborescence des composants et de l' interface utilisateur permet à JSF de soutenir différents langages de balisage (HTML vs XUL) ou dans des environnements de navigateur alternatifs (bureau vs smartphones).

La deuxième fonction de JSF est de répondre à des événements générés par l' utilisateur dans la page en invoquant les auditeurs côté serveur, suivie de la génération d' une autre interface utilisateur (par exemple, une page Web) ou une mise à jour de l'interface utilisateur affichées (éventuellement par le biais Ajax). À cet égard, JSF est dit être un cadre web événementiel.

Il est important de mentionner que JSF fait partie de la norme plateforme JAVA EE, ce qui signifie qu'il est intégré à un serveur d'applications Java EE compatible, comme WebLogic Oracle, GlassFish Open Source Edition ou JBoss AS. Mais il peut aussi être utilisé comme une bibliothèque autonome dans des conteneurs de servlet tels que Tomcat et Jetty.

JSF est principalement constitue de :

Un ensemble d'APIs pour la représentation et la gestion des composants, de leur état, des évènements, de la validation des entrées et la conversion des sorties, l'internationalisation et l'accessibilité ainsi que la navigation inter-vues

Deux jeux de composants standards (affichage de texte, saisie de texte, tables, zone à cocher, etc.) : html et core

Deux bibliothèques de balises JSP (une pour chaque jeu de composants) pour permettre l'utilisation des JSPs pour la construction de vues JSF

Un modèle évènementiel côté serveur

Les Managed-Beans : qui forment la couche contrôle de JSF

Langage d'expressions (EL) unifié pour JSF et JSP 2.0. Il permet de lier les composants aux managed-beans

 

JSF Architecture  

La vue est généralement assurée par des pages JSP ou par des pages XHTML (on parle alors de Facelets) ;

Le modèle est assuré par des entités ou des JavaBeans ;

Le contrôleur, auparavant incarné par nos servlets, est dorénavant décomposé en deux éléments :

  • une unique servlet mère servant de point d'entrée à toute requête, la FacesServlet ;
  • un JavaBean particulier, déclaré via une annotation et désigné par le terme managed-bean.

Le tout est mis en musique par des fichiers de configuration : le classique web.xml, mais également un nouveau fichier nommé faces-config.xml.

Nous observons que la différence majeure qui ressort jusqu'à présent est l'absence de servlets spécifiques à chaque page.

 

Le cycle de vie d’une application JSF comprend six phases :

 

 

Les six phases indiquent l’ordre dans lequel JSF traite un formulaire. La liste affiche les phases dans leur ordre d'exécution probable avec le traitement des événements à chaque phase.

 

Phase 1 : restaurer la vue

JSF commence la phase d'affichage de la restauration dès qu'un clic sur un lien ou un bouton est effectué et que JSF reçoit une demande.

Au cours de cette phase, JSF crée la vue, connecte les gestionnaires d’événements et les validateurs aux composants de l’interface utilisateur et enregistre la vue dans l’instance FacesContext. L'instance FacesContext contiendra désormais toutes les informations nécessaires au traitement d'une demande.

Phase 2 : Appliquer les valeurs de demande

Une fois que l’arborescence des composants est créée / restaurée, chaque composant de l’arborescence utilise la méthode de décodage pour extraire sa nouvelle valeur à partir des paramètres de la demande. Le composant stocke cette valeur. Si la conversion échoue, un message d'erreur est généré et mis en file d'attente sur FacesContext. Ce message sera affiché pendant la phase de réponse au rendu, avec toutes les erreurs de validation.

Si des écouteurs d'événements de méthodes de décodage appelés renderResponse sur l'instance actuelle de FacesContext, le fichier JSF passe à la phase de réponse.

Phase 3 : validation du processus

Au cours de cette phase, JSF traite tous les validateurs inscrits dans l'arborescence des composants. Il examine les règles d'attribut de composant pour la validation et les compare à la valeur locale stockée pour le composant.

Si la valeur locale n'est pas valide, JSF ajoute un message d'erreur à l'instance FacesContext et le cycle de vie avance à la phase de réponse et affiche à nouveau la même page avec le message d'erreur.

Phase 4 : Mise à jour des valeurs du modèle

Une fois que le fichier JSF a vérifié la validité des données, il parcourt l'arborescence des composants et définit les propriétés d'objet côté serveur correspondantes sur les valeurs locales des composants. JSF mettra à jour les propriétés du bean correspondant à l'attribut value du composant en entrée.

Si des méthodes updateModels appelées renderResponse sur l'instance actuelle de FacesContext, JSF passe à la phase de réponse du rendu.

Phase 5 : invoquer une application

Au cours de cette phase, JSF gère tous les événements au niveau de l'application, tels que la soumission d'un formulaire / la création de liens vers une autre page.

Phase 6 : Réponse de rendu

Au cours de cette phase, JSF demande au serveur de conteneur / d'application de restituer la page si l'application utilise des pages JSP. Pour la demande initiale, les composants représentés sur la page seront ajoutés à l'arborescence des composants au fur et à mesure que le conteneur JSP exécute la page. S'il ne s'agit pas d'une demande initiale, l'arborescence des composants est déjà créée, il n'est donc pas nécessaire de rajouter des composants. Dans les deux cas, les composants s'affichent lorsque le conteneur JSP / serveur d'applications traverse les balises de la page.

Une fois que le contenu de la vue est rendu, l'état de la réponse est enregistré afin que les requêtes suivantes puissent y accéder et qu'il soit disponible pour la phase d'affichage de la restauration.

 

Références

https://www.jmdoudoux.fr/java/dej/chap-jsf.htm

https://dzone.com/articles/jsf-2-seam-standardization

http://jsfcentral.com/

https://blog.ippon.fr/2011/04/27/jsf-je-taime-moi-non-plus/

https://fr.wikipedia.org/wiki/JavaServer_Faces

http://www.javaserverfaces.org/

https://openclassrooms.com/fr/courses/626954-creez-votre-application-web-avec-java-ee

https://javaee.github.io/javaserverfaces-spec/

https://javawiki.wordpress.com/2009/07/21/jsf-and-mvc/

https://blogs.oracle.com/theaquarium/why-another-mvc-framework-in-java-ee-8

https://stackoverflow.com/tags/jsf/info

 

 

 

 

 

 

 

 

 

 

 

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *