Premiers pas avec JSF : Qu'est-ce que JSF ? , Facelets et composants

Premiers pas avec JSF : Qu'est-ce que JSF ? , Facelets et composants(partie1) ,   WEBGRAM, meilleure entreprise / société / agence informatique basée à Dakar-Sénégal, leader en Afrique dans la formation en informatique :Système d'information, programmation, intelligence artificielle, développement web (python, java script, c, c++,  PHP), Framework (laravel, angular, react js, vue js, jQuery, ....), langages de programmations, système de gestion de base de données, système de gestion de base de données relationnelles, sécurité informatique, architecture logicielle, CMS, système réseau, gestion de projet informatique, développement mobile (Android et IOS), système d'exploitation (MacOs, Windows , Linux), NTIC (nouvelle technologie de l'information et de la communication), gestion des serveurs sous Windows et Ubuntu, web design, création de jeu vidéo, bureautique (pack office), infographie (pack Adobe), introduction au web, initiation au développement mobile, informatique de gestion, systèmes informatiques, administration des réseaux, communication digitale, législation dans le domaine du digitale, médias sociaux et culture digitale, manager IT, création visuelle, logiciel de montage, production audiovisuelle, requête HTTPS, introduction a ORACLE, fondamentaux du langage SQL, ORACLE administration avancée, administration de MySQL, outils décisionnels, formation en API rest , Visual studio, C# - développement avec le Framework .Net,  technologies web

Dans cette introduction au framework JSF, nous apprendrons en quoi il consiste en général, nous explorerons ses principaux composants, puis nous créerons un exemple très simple et enfin nous le comparerons à son homologue JSP.

Qu'est-ce que JSF ?

WEBGRAM, Agence N°1 du développement de système informatique / société / agence informatique basée à Dakar-Sénégal, leader en Afrique

Présentation

Comme mentionné dans le chapitre précédent, JSF (JavaServer Faces) est un cadre MVC basé sur des composants. Il est construit au-dessus de l'API Servlet et fournit des composants sous la forme de bibliothèques de balises, qui sont très similaires à JSTL. Ils peuvent être utilisés dans des pages JSP ainsi que dans toute autre technologie de présentation basée sur Java, car le cadre JSF ne limite pas le développeur à une technologie de présentation particulière. Cependant, il existe une technologie relativement nouvelle appelée Facelet, qui fait partie de la norme et dont l'utilisation est recommandée avec JSF car elle est beaucoup plus adaptée que les pages JSP. Les pages JSP ont été considérées comme une technologie de présentation dépréciée pour JSF depuis la sortie de Java EE 6 en 2009.

Outre les avantages inhérents à tout cadre MVC basé sur des composants, que nous avons énumérés dans le chapitre précédent, JSF offre des options étendues pour créer des modèles, tels que des composants composites.

Qu'est-ce que la création de modèles ?

En termes simples, il s'agit de la possibilité de diviser une page en plusieurs éléments indépendants, qui sont ensuite assemblés pour former une page finale. À cet égard, la technologie JSP ne fournit que la balise <jsp:include/>, que nous avons déjà vue dans notre TA pour une tâche très simple, qui consiste à inclure automatiquement un menu dans chacune de nos pages.

En bref, JSF, comme la plupart des frameworks MVC, nous permet de gérer les événements et la validation des entrées utilisateur, de gérer la navigation entre les pages, de créer des vues accessibles, de faciliter l'internationalisation des pages, etc. De plus, étant donné qu'elle est basée sur les composants plutôt que sur les requêtes, elle nous permet de gérer l'état d'une vue donnée. Pas de panique, nous reviendrons sur ces aspects importants en temps voulu et en pratique.

Principe

JSF est un cadre MVC et propose FacesServlet comme contrôleur unique pour le cycle de vie du traitement des demandes.

WEBGRAM, Leader de l'ingénierie logicielle / société / agence informatique basée à Dakar-Sénégal, leader en Afrique

Un seul contrôleur ?

Oui, vous avez bien lu, il n'y a qu'une seule servlet chargée de diriger toutes les demandes entrantes vers les bons composants, pour l'ensemble de l'application ! Cette architecture a un nom, c'est le modèle de contrôleur frontal, qui est lui-même une spécialisation du modèle de médiateur.

JSF vous évite d'avoir à écrire du code - du code standard, modèle et fastidieux - chargé de collecter les entrées de l'utilisateur (paramètres de requête HTTP), de les convertir et de les valider, de mettre à jour les données du modèle, d'appeler les actions métier et de générer la réponse. Tout ce que vous obtenez, c'est une page JSP ou XHTML (Facelet) comme vue et un JavaBean comme modèle. Cela accélère considérablement le développement ! Les composants JSF sont utilisés pour lier la vue au modèle, et FacesServlet utilise l'arbre des composants JSF pour faire tout le travail.

Tout cela semble très compliqué, mais il y a une chose que vous devez vraiment retenir : avec JSF, vous n'avez plus besoin d'écrire des servlets ! Ne soyez pas intimidé par toutes ces nouvelles fonctionnalités, nous y reviendrons calmement et en détail un peu plus loin dans ce chapitre.

Historique

Avant de poursuivre, jetons un coup d'œil au passé de la solution. Certains d'entre vous savent peut-être déjà que JSF a une certaine réputation parmi les développeurs... une mauvaise réputation ! Toutefois, si l'on y regarde de plus près, il apparaît rapidement que la plupart des récriminations à l'encontre de JSF ne sont pas fondées.

Pour se débarrasser de cette mauvaise réputation, hormis la question de la relative difficulté d'apprentissage lorsqu'on n'a pas de solides connaissances de Java EE (notamment des servlets), nous allons faire un rapide inventaire de l'évolution du framework depuis sa naissance jusqu'à aujourd'hui. Bien qu'il en soit actuellement à la version 2.1, il doit encore se défaire de l'image négative qu'il a développée lorsqu'il était encore immature. Et c'est vrai, si vous regardez son histoire, il y a de sérieux défauts...

Cette histoire contient quelques informations et détails qui vous échapperont certainement à la première lecture si vous n'avez jamais travaillé avec le JSF dans le passé. Ne vous y attardez pas pour l'instant, essayez simplement de comprendre l'évolution générale du cadre. Si vous rencontrez un jour un projet basé sur une ancienne version de JSF, vous trouverez ici les principales différences avec la version actuelle et les lacunes importantes.

WEBGRAM, N°1 du développement de logiciels/ société / agence informatique basée à Dakar-Sénégal, leader en Afrique

JSF 1.0 (mars 2004)

C'était la version originale. Malgré l'estampille 1.0, elle était pleine de bogues tant au niveau des performances que du noyau, vous ne pourriez pas le croire. Les applications ne fonctionnaient pas toujours comme prévu. En tant que développeur, vous auriez fui en hurlant devant cette solution !

JSF 1.1 (mai 2004)

Il s'agissait d'une mise à jour destinée à corriger des bogues dans la version initiale... Et la performance n'était toujours pas au rendez-vous. De plus, une énorme faille : il était impossible d'insérer du HTML dans une page JSF sans bogues ! Une décision étrange, dans un cadre conçu pour créer des applications web, de laisser les concepteurs web de côté... En bref, tout le code HTML brut a été transformé en balises JSF ! Ensuite, chaque morceau de code HTML devait être entouré d'une balise JSF (<f:verbatim>) afin qu'il puisse être correctement inclus dans l'arbre des composants (chaîne de balises JSF) et rendu proprement. Bien que conforme aux spécifications rédigées à l'époque, elle a suscité une avalanche de critiques ! Imaginez devoir entourer chaque balise HTML de vos pages JSP d'une autre balise pour qu'elle soit correctement prise en compte... En bref, c'était une véritable horreur.

JSF 1.2 (mai 2006)

Il s'agissait de la première version préparée par la nouvelle équipe de développement de JSF, dirigée par Ryan Luebke. L'équipe a beaucoup travaillé, et le cahier des charges a subi d'importantes modifications. Le principal objectif de ces changements était d'améliorer la gestion des vues. Cela a non seulement rendu la vue JSF indépendante de JSP, mais a également permis aux développeurs d'incorporer du HTML dans une page JSF sans avoir à dupliquer constamment ces ennuyeuses balises <f:verbatim> requises dans les versions précédentes. Un autre objectif de l'équipe à l'époque était d'améliorer les performances. Presque toutes les versions mineures des correctifs ont été accompagnées d'une amélioration significative des performances globales du cadre.

Le seul véritable défaut commun à toutes les versions de JSF 1.x (y compris la 1.2) était l'absence d'une zone de visibilité entre la demande et la session (souvent appelée "zone d'interaction"). Cela obligeait les développeurs à jouer avec des champs de formulaire cachés, des requêtes de base de données inutiles et/ou des sessions abusives chaque fois que quelqu'un voulait sauvegarder le modèle de données original pour des requêtes ultérieures afin d'effectuer la validation/conversion/mise à jour du modèle et invoquer des actions dans des applications web plus complexes. En bref, le développeur a dû faire ce que nous faisons lorsque nous travaillons manuellement sans framework. Il n'avait pas de moyen standard de donner raison à une opinion ou à une autre. À l'époque, ce problème pouvait être partiellement évité en utilisant des bibliothèques tierces qui sauvegardaient l'état des données nécessaires aux requêtes ultérieures, comme la balise <t:saveState> de la bibliothèque MyFaces Tomahawk ou le cadre de conversation MyFaces Orchestra.

WEBGRAM, Agence N°1 du développement de système informatique / société / agence informatique basée à Dakar-Sénégal, leader en Afrique

Une autre chose très ennuyeuse pour les concepteurs de sites Web était le fait que JSF utilisait le symbole : comme séparateur d'identifiant pour s'assurer que les identifiants des éléments HTML générés étaient uniques lors du rendu des balises, en particulier lorsqu'un composant était utilisé plusieurs fois dans une vue (création de modèles, boucles sur les composants, etc.) Si vous vous y connaissez en CSS, vous devez savoir que ce symbole n'est pas autorisé dans les identificateurs CSS. Les concepteurs de sites Web ont dû utiliser le symbole \ pour éviter le symbole : dans les sélecteurs CSS qu'ils ont configurés, ce qui a donné lieu à des sélecteurs bizarres et désordonnés comme #formId\:fieldId { ... } dans les feuilles CSS.

De plus, JSF 1.x n'était pas livré avec la fonctionnalité Ajax. Ce n'était pas vraiment un défaut technique, mais l'explosion du Web 2.0 en a fait un défaut fonctionnel. Exadel a rapidement introduit la bibliothèque Ajax4jsf, qui a été activement développée au cours des années suivantes, puis intégrée à la bibliothèque de composants de base de JBoss RichFaces. Depuis, d'autres bibliothèques ont proposé des composants compatibles avec Ajax, dont la plus connue est IceFaces.

Lorsque JSF 1.2 a atteint la moitié de son cycle de vie, une nouvelle technologie a été introduite pour la présentation basée sur XML : Facelets. Cela offrait d'énormes avantages par rapport à JSP, notamment en termes de création de modèles et de performances.

JSF 2.0 (juin 2009)

Il s'agissait de la deuxième version majeure. Les changements ont été nombreux, tant sur le plan technique que fonctionnel. La technologie JSP a été remplacée par Facelets comme technologie de présentation par défaut, et Facelets a été étendu avec des fonctionnalités pour créer des composants XML propres (appelés composants composites). En particulier, Ajax a été introduit, en utilisant un composant qui a des similitudes avec Ajax4jsf. Des annotations et des améliorations prenant en charge le concept de convention plus configuration ont été introduites pour éliminer autant que possible les fichiers de configuration volumineux et verbeux. En outre, le caractère de délimitation de l'identifiant : est devenu personnalisable.

WEBGRAM, Leader de l'ingénierie logicielle / société / agence informatique basée à Dakar-Sénégal, leader en Afrique

Enfin, une nouvelle zone de visibilité a été introduite : la zone de visibilité qui se situe entre la demande et la session. Cela a permis de surmonter un autre défaut majeur de JSF 1.x, comme nous l'avons vu précédemment. Nous y reviendrons en détail dans un prochain exemple pratique.

Jusqu'à présent, tout semble idyllique, et cette version 2.0 semble être une bouée de sauvetage. Cependant, si la plupart des défauts de JSF 1.x ont disparu dans cette version, il reste des bogues spécifiques à JSF 2.0 qui peuvent être un facteur bloquant lors du développement d'une application. Si vous en avez envie, vous pouvez jeter un coup d'œil aux bogues de JSF 2.x pour vous faire une idée, mais ils concernent l'utilisation avancée du framework, et la plupart de ces bogues sont de toute façon solubles.

Enfin, pour terminer sur une note plus joyeuse, c'est JSF 2.0 qui a introduit de nouvelles bibliothèques de composants plus graphiques. Nous pouvons citer les impressionnants PrimeFaces et OpenFaces.

MVC basé sur les composants et MVC basé sur les requêtes

Certains affirment que le plus gros inconvénient de JSF est qu'il permet peu de contrôle sur le code HTML/CSS/JS généré. Cela n'a rien à voir avec JSF lui-même, mais le fait qu'il s'agisse d'un cadre MVC basé sur des composants plutôt que sur des requêtes (actions). Si vous êtes confus, je vous renvoie au chapitre précédent pour les définitions.

C'est vraiment très simple : si un haut niveau de contrôle sur le rendu HTML/CSS/JS est votre principale exigence lors du choix d'un framework MVC, alors vous devriez envisager des frameworks basés sur les requêtes tels que Spring MVC.

Après cette longue digression sur l'histoire de JSF, que vous pouvez retrouver sur cette page, résumons la situation en quelques lignes :

WEBGRAM, N°1 du développement de logiciels/ société / agence informatique basée à Dakar-Sénégal, leader en Afrique

- JSF 2.0 est un cadre MVC basé sur le Web qui se concentre sur la simplification de la construction des interfaces utilisateur, en d'autres termes, des vues. Il propose plus d'une centaine de balises à cet effet et permet de réutiliser facilement les composants d'une interface utilisateur à l'autre ;

- Dans JSF 1, tout devait être déclaré dans un fichier de configuration, et le développeur devait donc maintenir un dixième fichier XML... Dans JSF 2, ces fichiers (inter)minables ne sont plus nécessaires : les annotations remplacent les fichiers externes, et le développement est grandement accéléré et simplifié !

- Dans ce cours, je ne ferai plus jamais de distinction entre JSF 1 et JSF 2, tout simplement parce que JSF aujourd'hui est JSF 2 et rien d'autre. Cela devrait être tout aussi clair dans votre esprit : JSF 1 est de l'histoire ancienne, et je ne le mentionnerai qu'en passant pour vous informer des différences importantes par rapport à la version actuelle, afin que vous ne soyez pas trop surpris si vous devez un jour travailler sur une application développée sur JSF 1 (ce que je ne vous souhaite évidemment pas !).

Les ressources obsolètes sur JSF abondent sur le web ! De nombreux cours, didacticiels, fils de forum et documentations portent sur JSF 1, alors que JSF 2 a subi des changements importants. Faites attention aux liens que vous consultez, et utilisez les dates clés de l'histoire du JSF pour déterminer si les informations que vous lisez sont à jour ou non. En règle générale, il faut se méfier de tout ce qui a été publié avant 2009 !

WEBGRAM est leader (meilleure entreprise / société / agence) de développement d'applications web et mobiles, et de progiciel de gestion intégré (ERP - Entreprise Resource Planning) en Afrique (Sénégal, Côte d’Ivoire, Bénin, Gabon, Burkina Faso, Mali, Guinée, Cap-Vert, Cameroun, Madagascar, Centrafrique, Gambie, Mauritanie, Niger, Rwanda, Congo-Brazzaville, Congo-Kinshasa RDC, Togo).