Quels sont les principaux inconvénients de Java Server Faces 2.0?

Hier, j'ai vu une présentation sur Java Server Faces 2.0 qui semblait vraiment impressionnante, même si je suis actuellement un développeur ASP.NET MVC / jQuery heureux. Ce que j'aimais le plus à propos de JSF était l'énorme quantité de composants d'interface utilisateur compatibles AJAX qui semblent rendre le développement beaucoup plus rapide qu'avec ASP.NET MVC, en particulier sur les sites AJAX. Les tests d'intégration étaient également très agréables.

Étant donné que la présentation n'a souligné que les avantages de JSF, j'aimerais également entendre parler de l'autre côté.

Mes questions sont donc:

• Quels sont les principaux inconvénients de Java Server Faces 2.0?
• Qu'est-ce qui pourrait inciter un développeur JSF à utiliser ASP.NET MVC au lieu de JSF?

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 iddans 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.xmlfichier 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-paramdans web.xmlle nom javax.faces.SEPARATOR_CHARet 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 @ViewScopedpour 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 @ViewScopedbean 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:

• Quelle est la différence entre JSF, Servlet et JSP? (juste pour comprendre les bases)
• Utiliser JSF pour développer des dispositions CSS sans table (un autre mythe à propos de JSF)
• JSF vs HTML / CSS / JS / jQuery standard (lorsque JSF n'est pas le bon choix)
• Modèles de conception dans les applications Web (illustre l'idéologie derrière MVC)

Après 5 ans de travail avec JSF, je pense que je peux ajouter mes 2 cents.

Deux inconvénients majeurs de JSF :

1. Grande courbe d'apprentissage. JSF est complexe, c'est juste vrai.
2. Sa nature composante . Le cadre basé sur les composants tente de cacher la vraie nature du Web, qui s'accompagne d'une énorme quantité de complications et de catastrophes (comme ne pas prendre en charge GET dans JSF dans près de 5 ans).
   À mon humble avis, cacher la requête / réponse HTTP du développeur est une énorme erreur. D'après mon expérience, chaque infrastructure basée sur des composants ajoute une abstraction au développement Web, et cette abstraction entraîne des frais généraux inutiles et une complexité plus élevée.

Et les inconvénients mineurs qui me viennent à l'esprit:

1. Par défaut, l'ID de l'objet est composé des ID de ses parents, par exemple form1: button1.
2. Pas de moyen facile de commenter un fragment de page incorrect. La balise a <ui:remove>besoin d'un contenu syntaxiquement correct qui est de toute façon analysé.
3. Faible qualité composants 3ème partie qui par exemple ne vérifient pas l' isRendered()intérieur de la processXxx()méthode avant de continuer.
4. Intégrer LESS & Sencha est difficile.
5. Ne joue pas bien avec REST.
6. Pas si facile pour les concepteurs UX, car les composants prêts à l'emploi ont leurs propres styles CSS, qui doivent être remplacés.

Ne vous méprenez pas. En tant que framework de composants, JSF dans la version 2 est vraiment bon, mais il est toujours basé sur les composants, et le sera toujours ...

Veuillez jeter un œil à la faible popularité de Tapestry, Wicket et au faible enthousiasme des développeurs JSF expérimentés (ce qui est encore plus significatif). Et pour le contraste, jetez un œil au succès de Rails, Grails, Django, Play! Framework - ils sont tous basés sur l'action et n'essaient pas de cacher au programmeur la vraie demande / réponse et la nature sans état du Web.

Pour moi, c'est un inconvénient majeur de JSF. IMHO JSF peut convenir à certains types d'applications (intranet, à forte intensité de formulaires), mais pour une application Web réelle , ce n'est pas une bonne façon de procéder.

J'espère que cela aide quelqu'un avec ses choix en ce qui concerne le front-end.

Quelques inconvénients qui me viennent à l'esprit:

1. JSF est un framework basé sur des composants. Cela a des restrictions inhérentes qui ont à voir avec le respect du modèle de composant.
2. AFAIK JSF ne prend en charge que le POST, donc si vous voulez un GET quelque part, vous devez faire un servlet / JSP simple.
3. La plupart des composants essaient de fournir des abstractions sur des domaines comme les bases de données relationnelles et le JavaScript frontal, et la plupart du temps, ces abstractions sont "fuyantes" et très difficiles à déboguer.
4. Ces abstractions peuvent être un bon point de départ pour un développeur junior ou quelqu'un qui n'est pas à l'aise avec un domaine particulier (par exemple JavaScript frontal), mais sont très difficiles à optimiser pour les performances, car plusieurs couches sont impliquées et la plupart des gens qui les utilisent ont peu de compréhension de ce qui se passe sous le capot.
5. Les mécanismes de modélisation généralement utilisés avec JSF n'ont rien à voir avec le fonctionnement des concepteurs Web. Les éditeurs WYSIWYG pour JSF sont primitifs et dans tous les cas, votre concepteur vous donnera du HTML / CSS que vous devrez passer des années à convertir.
6. Des choses comme les expressions EL ne sont pas vérifiées statiquement et le compilateur et les IDE ne font pas du bon travail pour trouver les erreurs, donc vous vous retrouverez avec des erreurs que vous devrez attraper au moment de l'exécution. Cela pourrait être bien pour un langage typé dynamiquement comme Ruby ou PHP, mais si je dois supporter le ballonnement de l'écosystème Java, je demande la saisie pour mes modèles.

Pour résumer: le temps que vous gagnerez avec JSF, en évitant d'écrire le code passe-partout JSP / servlet / bean, vous l'avez dépensé x10 pour le faire évoluer et faire exactement ce que vous voulez qu'il fasse.

Pour moi, le plus grand inconvénient de JSF 2.0 est la courbe d'apprentissage non seulement de JSF, mais aussi les bibliothèques de composants que vous devez utiliser pour lui permettre de faire un travail utile. Considérez le nombre impressionnant de spécifications et de normes avec lesquelles vous avez affaire pour être vraiment compétent:

• HTML dans les différentes incarnations. Ne prétendez pas que vous n'avez pas besoin de le savoir.
• HTTP - lorsque vous ne pouvez pas comprendre ce qui se passe, vous devez ouvrir Firebug et voir. Pour cela, vous devez le savoir.
• CSS - Qu'on le veuille ou non. Ce n'est pas si mal vraiment et il y a au moins de bons outils.
• XML - JSF sera probablement le premier endroit où vous utiliserez des espaces de noms à ce degré.
• Spécification de servlet. Tôt ou tard, vous entrerez dans les méthodes d'appel dans ce package. En dehors de cela, vous devez savoir comment vos facettes sont transformées en XHTML ou autre.
• JSP (surtout pour savoir pourquoi vous n'en avez pas besoin dans JSF)
• JSTL (encore une fois, principalement pour faire face au cadre hérité)
• Expression Language (EL) sous ses différentes formes.
• ECMAScript, JavaScript ou tout autre nom que vous souhaitez utiliser.
• JSON - vous devez le savoir même si vous ne l'utilisez pas.
• AJAX. Je dirais que JSF 2.0 fait un travail décent de vous cacher cela, mais vous devez toujours savoir ce qui se passe.
• Le DOM. Et comment un navigateur l'utilise. Voir ECMAScript.
• Événements DOM - un sujet à lui tout seul.
• Java Persistence Architecture (JPA), c'est-à-dire si vous voulez que votre application ait une base de données principale.
• Java lui-même.
• JSEE pendant que vous y êtes.
• La spécification d'injection de dépendance de contexte (CDI) et comment elle se heurte à et est utilisée avec JSF 2.0
• JQuery - Je voudrais vous voir vous en sortir.

Maintenant, une fois que vous avez terminé, vous pouvez continuer avec les spécifications propriétaires, à savoir les bibliothèques de composants et les bibliothèques de fournisseurs que vous choisirez en cours de route:

• PrimeFaces (ma bibliothèque de composants de choix)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (mon fournisseur JPA)
• Hiberner
• Souder

Et n'oubliez pas le conteneur! Et tous ces fichiers de configuration:

• GlassFish (2, 3, etc.)
• JBoss
• Matou

Alors - C'EST FACILE? Bien sûr, JSF 2.0 est "facile" tant que tout ce que vous voulez faire est les pages Web les plus élémentaires avec les interactions les plus simples.

En termes simples, JSF 2.0 est le méli-mélo de technologies collées les plus compliquées et les plus complexes qui existe dans l'univers logiciel aujourd'hui. Et je ne pense à rien que je préfère utiliser.

1. Les développeurs inexpérimentés créent généralement des applications qui sont douloureusement lentes et le code sera vraiment moche et difficile à maintenir. Son trompeusement simple pour commencer, mais nécessite en fait un certain investissement dans l'apprentissage si vous voulez écrire de bons programmes.
2. Au moins au début, vous serez souvent «coincé» sur un problème et passerez plus de temps à lire des messages balusc sur Internet qu'à travailler réellement :) Après un certain temps, ce sera de moins en moins, mais cela peut toujours être ennuyeux.
3. Encore plus ennuyeux lorsque vous découvrez que le problème n'est pas dû à votre manque de connaissances / erreur mais à un bug. Mojarra était (est?) Assez bogué, et une autre couche de composants ajoute encore plus de problèmes. Richfaces était le plus gros logiciel de merde jamais écrit :) Je ne sais pas comment il est maintenant sur la version 4. Nous avons Primefaces qui est mieux, mais vous rencontrerez toujours des bugs ou un manque de fonctionnalités, en particulier avec des composants plus exotiques. Et maintenant, vous devrez payer pour les mises à jour Primefaces. Je dirais donc que son buggy mais son amélioration s'améliore surtout après que la version 2.2 a corrigé quelques problèmes avec les spécifications. Le framework devient plus mature mais toujours loin d'être parfait (peut-être que mes visages sont meilleurs?).
4. Je ne le trouve pas particulièrement flexible. Souvent, si vous avez besoin de quelque chose de très personnalisé et qu'aucun composant ne le fait, cela sera un peu douloureux. Encore une fois, je parle du point de vue du développeur moyen - celui avec des délais, des didacticiels de lecture rapide et la recherche de stackoverflow lorsque vous êtes bloqué car vous n'avez pas le temps d'apprendre comment cela fonctionne vraiment :) Souvent, certains composants semblent avoir "presque" ce dont vous avez besoin, mais pas exactement et parfois vous pourriez passer trop de temps à le faire faire ce que vous voulez :) Besoin d'être prudent dans l'évaluation s'il est préférable de créer votre propre composant ou de torturer un composant existant. En fait, si vous créez quelque chose de vraiment unique, je ne recommanderais pas JSF.

Donc en bref mes inconvénients seraient: Complexité, Progrès de développement pas très fluide, buggy, inflexible.

Bien sûr, il y a aussi des avantages, mais ce n'est pas ce que vous avez demandé. Quoi qu'il en soit, c'est mon expérience avec le cadre que d'autres pourraient avoir des opinions différentes, donc le meilleur moyen est de l'essayer pendant un certain temps pour voir si c'est pour vous (juste quelque chose de plus complexe - des exemples pas naïfs - JSF brille vraiment là :) IMHO meilleur cas d'utilisation pour JSF est des applications métier, comme les CRM etc ...

"JSF produira du HTML et du JavaScript de couche d'affichage que vous ne pouvez pas contrôler ou modifier sans entrer dans le code du contrôleur."

En fait, JSF vous donne la flexibilité, vous pouvez soit utiliser des composants standard / tiers ou créer les vôtres dont vous avez le contrôle total sur ce qui est rendu. C'est juste un xhtml dont vous avez besoin pour créer vos composants personnalisés avec JSF 2.0.

Je ne suis pas du tout un expert de Java Server Faces. Mais à mon humble avis, le principal inconvénient est qu'il est côté serveur. Je suis fatigué d'apprendre et d'utiliser des cadres de couche de présentation Web côté serveur comme les formulaires Web ASP.NET, ASP.NET MVC, Java Server Faces, Struts, les cadres PHP et les cadres Ruby on Rails. J'ai dit au revoir à tous, et j'ai dit bonjour à Angularjs et TypeScript. Ma couche de présentation s'exécute sur le navigateur. Peu importe s'il est servi par Windows IIS exécutant php ou ASP.NET, ou s'il est servi par un serveur Web Apache fonctionnant sous Linux. J'ai juste besoin d'apprendre un seul framework qui fonctionne partout.

Juste mes deux cents.

Nous avons développé un exemple de projet avec JSF (Il s'agissait d'une recherche de trois semaines, nous pourrions donc avoir perdu certaines choses!)

Nous essayons d'utiliser core jsf, si un composant est nécessaire, nous utilisons PrimeFaces.

Le projet était un site Web avec navigation. Chaque page doit être chargée via ajax lorsque le menu est cliqué.

Le site a deux cas d'utilisation:

1. Une page avec une grille. La grille est chargée via ajax et devrait prendre en charge le tri et la pagination
2. Une page de l'assistant en trois étapes. Chaque page a une validation côté client (pour les validations simples) et une validation de base ajax côté serveur (pour les validations complexes). Toute exception de serveur (de la couche de service) doit être affichée sur la même page de l'assistant sans passer à la page suivante.

Nous avons trouvé que:

1. Vous devez utiliser certains hacks d'omniFaces pour rendre l'état d'affichage JSF fixe. L'état JSF sera corrompu lorsque vous incluez des pages via ajax les unes dans les autres. Cela semble être un bogue dans JSF et pourrait être corrigé dans les prochaines versions (pas en 2.3).
2. Le flux JSF ne fonctionne pas correctement avec ajax (ou nous n'avons pas pu le faire fonctionner!) Nous essayons d'utiliser le composant de l'assistant primeface à la place, mais la validation du client ne semble pas prise en charge et signifie que ce n'était pas la norme de flux JSF standard.
3. Lorsque vous utilisez certains composants jQuery comme jqGird, et que vous devez charger les résultats JSON, il est conseillé d'utiliser un servlet pur, le JSF ne fera rien pour vous. Donc, si vous utilisez ce type de composants, votre conception ne rentrera pas dans JSF.
4. Nous essayons de faire quelques scripts client lorsque ajax se termine ajaxCompleteet nous avons constaté que le PF 4 a implémenté ses propres événements ajax. Nous avions quelques composants jQuery et nous devons changer leur code.

Si vous remplacez l'exemple ci-dessus par un non Ajax projet (ou au moins un projet moins ), vous ne rencontrerez pas beaucoup de problèmes ci-dessus.

Nous résumons notre recherche comme:

JSF ne fonctionne pas bien dans un site Web de base entièrement ajax.

Bien sûr, nous trouvons beaucoup de fonctionnalités intéressantes dans JSF qui peuvent être très utiles dans certains projets, alors considérez les besoins de votre projet.

Veuillez vous référer aux documents techniques JSF pour passer en revue les avantages JSF, et à mon avis le plus grand avantage de JSF, est le support COMPLET ET ÉNORME de @BalusC ;-)

Pour moi, la plus grande lacune de JSF est le faible support des pages générées par programme (dynamiquement).
Si vous souhaitez construire votre page (créer un modèle de composant de page) dynamiquement à partir du code java. Par exemple, si vous travaillez sur le constructeur de page Web WYSIWYG. La documentation adéquate de ce cas d'utilisation n'est généralement pas disponible. Il y a de nombreux points où vous devez expérimenter et le développement est lent et lent. Beaucoup de choses ne fonctionnent tout simplement pas comme prévu. Mais généralement, son possible pirater en quelque sorte.
Heureusement, ce n'est pas un problème de philosophie ou d'architecture JSF. Ce n'est tout simplement pas assez élaboré (pour autant que je sache).

JSF 2 a apporté des composants composites qui devraient faciliter le développement de composants, mais leur support pour la construction dynamique (programmatique) est très faible. Si vous surmontez un processus silencieux, compliqué et presque non documenté de construction dynamique de Composite Composite, vous découvrirez que Si vous imbriquez quelques composants Composite un peu plus profondément, ils cessent de fonctionner, levant quelques exceptions.

Mais il semble que la communauté JSF soit consciente de ces lacunes. Ils y travaillent comme vous pouvez le voir sur ces deux bogues
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

La situation devrait être meilleure avec JSF 2.2 au moins si nous parlons de spécification.

Commentant mes derniers mois d'expérience Primefaces / JSF:

• Si vous pouvez utiliser des composants "sur étagère", je suppose que ce n'est pas terrible.
• Cependant, il ne fonctionne pas bien dès que vous sortez et avez besoin d'interfaces utilisateur personnalisées. - Par exemple, nous devions utiliser le bootstrap de Twitter pour notre projet. (Pas bootstrap primefaces).
  • Maintenant, nos pages fonctionnent comme suit:
    • Charges de page.
    • L'utilisateur interagit avec un Primefaces doté d'une fonctionnalité ajax
    • Rupture des liaisons javascript de Bootstrap
    • Nous exécutons du javascript supplémentaire pour tout relier

La promesse de JSF d'éviter d'écrire du javascript s'est transformée en l'écriture de plus de javascript que si nous n'utilisions pas Primefaces - et ce javascript est de corriger ce que Primefaces casse.

C'est une perte de temps - à moins que vous n'utilisiez à nouveau des trucs «prêts à l'emploi». Aussi vraiment moche (Primefaces) quand on doit travailler avec Selenium. Tout peut être fait - mais encore une fois - il ne reste que peu de temps.

Évitez absolument cela si vous travaillez avec une équipe UX / conception et que vous devez rapidement itérer sur l'interface utilisateur - vous pouvez gagner du temps en apprenant jquery / en écrivant du HTML direct - ou en regardant réagir / angulaire.

JSF a de nombreux avantages, la question étant désavantagée, permettez-moi d'ajouter quelques points.

Sur un scénario pratique de mise en œuvre d'un projet Web avec dans un laps de temps, vous devez garder un œil sur les facteurs suivants.

• Avez-vous suffisamment de membres seniors dans votre équipe qui peuvent suggérer les meilleurs contrôles adaptés à chaque scénario?

• Avez-vous la bande passante pour accueillir la courbe d'apprentissage initiale?

• Avez-vous suffisamment d'expertise dans votre équipe qui peut examiner les
  éléments JSF produits par les développeurs?

Si votre réponse est «Non» aux questions, vous pouvez vous retrouver dans une base de code non gérable.

JSF n'a qu'un inconvénient: avant de commencer le développement "JSF", vous devez comprendre clairement le développement Web, le noyau Java et l'architecture frontale.

De nos jours, les "nouveaux" frameworks JavaScript essaient simplement de copier / coller le modèle basé sur les composants "JSF".

Parmi tous les cadres "grand public" tels que Spring MVC, Wicket, Tapestry, etc., le JSF de Java EE avec ses composants composites est la technologie de couche de présentation et orientée composants la plus élaborée. C'est un peu lourd et incomplet par rapport aux solutions fournies par HybridJava.