Inconvénients de JSF 2.0? Honnêtement, à part la courbe d'apprentissage relativement abrupte lorsque vous n'avez pas de solides connaissances de base sur le développement Web de base (HTML / CSS / JS, côté serveur contre côté client, etc.) et l' API Java Servlet de base (demande / réponse / session , transfert / redirection, etc.), aucun inconvénient sérieux ne vient à l'esprit. JSF dans sa version actuelle doit encore se débarrasser de l'image négative qu'elle a acquise au cours des premiers âges, au cours de laquelle il y avait plusieurs inconvénients graves.
JSF 1.0 (mars 2004)
C'était la version initiale. Il était encombré de bogues dans les domaines de base et de performance que vous ne voulez pas connaître. Votre application Web n'a pas toujours fonctionné comme vous vous y attendez intuitivement. En tant que développeur, vous fuiriez en pleurant.
JSF 1.1 (mai 2004)
C'était la version de correction de bogue. La performance n'était pas encore beaucoup améliorée. Il y avait aussi un inconvénient majeur: vous ne pouvez pas intégrer HTML correctement dans la page JSF. Tout le HTML vanille simple est rendu avant l'arborescence des composants JSF. Vous devez envelopper toutes les vanilles ordinaires dans des <f:verbatim>
balises afin qu'elles soient incluses dans l'arborescence des composants JSF. Bien que cela soit conforme aux spécifications, cela a fait l'objet de nombreuses critiques. Voir aussi ao JSF / Facelets: pourquoi n'est-ce pas une bonne idée de mélanger JSF / Facelets avec des balises HTML?
JSF 1.2 (mai 2006)
Ce fut la première version de la nouvelle équipe de développement JSF dirigée par Ryan Lubke. La nouvelle équipe a fait un excellent travail. Il y a également eu des changements dans les spécifications. Le changement majeur a été l'amélioration de la gestion des vues. Non seulement JSF était complètement détaché de JSP, donc on pouvait utiliser une technologie de vue différente de JSP, mais cela permettait également aux développeurs d'insérer du HTML vanille dans la page JSF sans avoir à utiliser de <f:verbatim>
balises. Un autre objectif majeur de la nouvelle équipe était l'amélioration des performances. Pendant la durée de vie de l'implémentation de référence Sun JSF 1.2 (qui porte le nom de code Mojarra depuis la version 1.2_08, vers 2008), pratiquement chaque version a été livrée avec des améliorations de performances (majeures) à côté des corrections de bogues habituelles (mineures).
Le seul inconvénient sérieux de JSF 1.x (y compris 1.2) est le manque de portée entre la portée de la demande et de la session , la portée dite de conversation . Cela a forcé les développeurs à se tracasser avec des éléments d'entrée cachés, des requêtes DB inutiles et / ou à abuser de la portée de la session chaque fois que l'on veut conserver les données initiales du modèle dans la demande suivante afin de traiter avec succès les validations, les conversions, les changements de modèle et les invocations d'actions dans le plus applications web complexes. La douleur pourrait être adoucie en adoptant une bibliothèque tierce qui conserve les données nécessaires dans la demande suivante comme le composant MyFaces Tomahawk <t:saveState>
, la portée de conversation JBoss Seam et MyFaces Orchestra cadre de conversation.
Un autre inconvénient pour les puristes HTML / CSS est que JSF utilise les deux points :
comme caractère séparateur d'ID pour garantir l'unicité de l'élément HTML id
dans la sortie HTML générée, en particulier lorsqu'un composant est réutilisé plusieurs fois dans la vue (modèles, itération de composants, etc.) . Comme il s'agit d'un caractère illégal dans les identificateurs CSS, vous devez utiliser le \
pour échapper aux deux points dans les sélecteurs CSS, ce qui entraîne des sélecteurs laids et étranges comme #formId\:fieldId {}
ou même #formId\3A fieldId {}
. Voir aussi Comment utiliser l'ID d'élément HTML généré par JSF avec deux points ":" dans les sélecteurs CSS? Cependant, si vous n'êtes pas un puriste, lisez également Par défaut, JSF génère des identifiants inutilisables, qui sont incompatibles avec la partie CSS des normes Web .
De plus, JSF 1.x n'a pas été livré avec les installations Ajax prêtes à l'emploi. Pas vraiment un inconvénient technique, mais en raison du battage médiatique du Web 2.0 au cours de cette période, il est devenu un inconvénient fonctionnel. Exadel a été très tôt pour introduire Ajax4jsf, qui a été soigneusement développé au cours des années et est devenu le cœur de la bibliothèque de composants JBoss RichFaces . Une autre bibliothèque de composants a également été livrée avec des pouvoirs Ajax intégrés, le plus connu étant ICEfaces .
Vers la moitié de la durée de vie de JSF 1.2, une nouvelle technologie de vue basée sur XML a été introduite: Facelets . Cela offrait d'énormes avantages par rapport à JSP, en particulier dans le domaine des modèles.
JSF 2.0 (juin 2009)
Il s'agissait de la deuxième version majeure, avec Ajax comme mot à la mode. Il y a eu beaucoup de changements techniques et fonctionnels. JSP est remplacé par Facelets en tant que technologie d'affichage par défaut et Facelets a été étendu avec des capacités pour créer des composants personnalisés en utilisant du XML pur (les composants dits composites ). Voir aussi Pourquoi Facelets est préféré à JSP comme langage de définition de vue à partir de JSF2.0?
Les pouvoirs Ajax ont été introduits dans la saveur du <f:ajax>
composant qui présente de nombreuses similitudes avec Ajax4jsf. Des annotations et des améliorations de la convention sur la configuration ont été introduites pour tuer le faces-config.xml
fichier détaillé autant que possible. De plus, le caractère de séparateur d'ID de conteneur de nommage par défaut :
est devenu configurable, de sorte que les puristes HTML / CSS pouvaient respirer. Tout ce que vous devez faire est de le définir comme init-param
dans web.xml
le nom javax.faces.SEPARATOR_CHAR
et veiller à ce que vous n'utilisez pas le caractère vous importe où dans son client d'identité, par exemple -
.
Enfin et surtout, une nouvelle portée a été introduite, la portée de la vue . Il a éliminé un autre inconvénient majeur de JSF 1.x comme décrit précédemment. Vous déclarez simplement le bean @ViewScoped
pour activer la portée de la conversation sans vous soucier de toutes les façons de conserver les données dans les demandes (conversationnelles) suivantes. Un @ViewScoped
bean vivra aussi longtemps que vous soumettez et naviguez vers la même vue (indépendamment de l'onglet / fenêtre du navigateur ouvert!), De manière synchrone ou asynchrone (Ajax). Voir aussi Différence entre la portée de la vue et de la demande dans les beans gérés et Comment choisir la bonne portée du bean?
Bien que pratiquement tous les inconvénients de JSF 1.x aient été éliminés, il existe des bogues spécifiques à JSF 2.0 qui pourraient devenir un showstopper. L' @ViewScoped
échec dans les gestionnaires de balises en raison d'un problème d'oeufs de poule dans la sauvegarde d'état partielle. Ceci est corrigé dans JSF 2.2 et rétroporté dans Mojarra 2.1.18. La transmission d'attributs personnalisés tels que HTML5data-xxx
n'est pas non plus prise en charge. Ceci est corrigé dans JSF 2.2 par une nouvelle fonctionnalité d'éléments / attributs passthrough. En outre, la mise en œuvre de JSF Mojarra a son propre ensemble de problèmes . Relativement beaucoup d'entre eux sont liés au comportement parfois peu intuitif de<ui:repeat>
, la nouvelle implémentation de sauvegarde d'état partiel et la portée flash mal implémentée . La plupart d'entre eux sont corrigés dans une version Mojarra 2.2.x.
Autour de JSF 2.0, PrimeFaces a été introduit, basé sur jQuery et jQuery UI. Il est devenu la bibliothèque de composants JSF la plus populaire.
JSF 2.2 (mai 2013)
Avec l'introduction de JSF 2.2, HTML5 a été utilisé comme mot à la mode même s'il n'était techniquement pris en charge que dans toutes les anciennes versions de JSF. Voir aussi la prise en charge de JavaServer Faces 2.2 et HTML5, pourquoi XHTML est-il toujours utilisé . La nouvelle fonctionnalité JSF 2.2 la plus importante est la prise en charge des attributs de composants personnalisés, ouvrant ainsi un monde de possibilités, telles que des groupes de boutons radio sans tableau personnalisés .
Mis à part les bogues spécifiques à l'implémentation et certaines "petites choses ennuyeuses" telles que l'impossibilité d'injecter un EJB dans un validateur / convertisseur (déjà corrigé dans JSF 2.3), il n'y a pas vraiment d'inconvénients majeurs dans la spécification JSF 2.2.
MVC basé sur les composants vs MVC basé sur les demandes
Certains peuvent choisir que l'inconvénient majeur de JSF est qu'il permet très peu de contrôle fin sur le HTML / CSS / JS généré. Ce n'est pas le propre de JSF, c'est simplement parce que c'est un framework MVC basé sur des composants , pas un framework MVC basé sur une demande (action) . Si un haut niveau de contrôle du HTML / CSS / JS est votre principale exigence lorsque vous envisagez un framework MVC, vous ne devriez pas déjà regarder un framework MVC basé sur des composants, mais un framework MVC basé sur une demande comme Spring MVC . Il vous suffit de tenir compte du fait que vous devrez écrire vous-même tout ce passe-partout HTML / CSS / JS. Voir aussi Différence entre MVC de demande et MVC de composant .
Voir également: