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

Question

Hier, j’ai assisté à une présentation sur Java Server Faces 2.0, qui était vraiment impressionnante, même si je suis actuellement un développeur ASP.NET MVC/jQuery heureux. Ce que j’ai le plus aimé de JSF est l’énorme Composants d'interface utilisateur prenant en charge AJAX, qui semblent rendre le développement beaucoup plus rapide qu'avec ASP.NET MVC, en particulier sur les sites utilisant une capacité AJAX élevée.

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

Donc mes questions sont:

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

Answer 1

JSF 2.0 inconvénients? Honnêtement, mis à part la courbe d’apprentissage relativement abrupte lorsque vous n’avez pas une connaissance approfondie de développement Web de base (HTML/CSS/JS, côté serveur par rapport au côté client, etc.) et le basic Java API Servlet (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 la image négative qu’elle a acquise au début de l’âge, au cours de laquelle il y a eu plusieurs inconvénients graves.

JSF 1.0 (mars 2004)

C'était la version initiale. Il était encombré de bugs affectant à la fois les domaines essentiels et les performances que vous ne souhaitiez pas connaître. Votre application Web n'a pas toujours fonctionné comme prévu. En tant que développeur, vous courriez beaucoup en pleurant.

JSF 1.1 (mai 2004)

C'était la version de correction de bug. La performance n'était pas encore beaucoup améliorée. Il y avait aussi un inconvénient majeur: vous ne pouvez pas parfaitement insérer du HTML dans la page JSF. Tous les fichiers plain Vanilla HTML sont rendus avantl’arborescence des composants JSF. Vous devez envelopper toute la vanille dans <f:verbatim> balises afin qu’elles soient incluses dans l’arborescence des composants JSF. Bien que ce soit conforme à la spécification, cela a reçu beaucoup de critiques. Voir aussi a.o. 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)

Il s'agissait de la première publication de la nouvelle équipe de développement JSF dirigée par Ryan Lubke. La nouvelle équipe a fait beaucoup de bon travail. Il y avait aussi des changements dans les spécifications. Le changement majeur a été l'amélioration de la gestion de la vue. Non seulement ce fichier JSF était complètement détaché de JSP, il était donc possible d'utiliser une technologie d'affichage différente de celle de JSP, mais il permettait également aux développeurs d'insérer du code HTML Vanilla simple dans la page JSF sans avoir à manipuler <f:verbatim> Mots clés. Un autre objectif majeur de la nouvelle équipe était l'amélioration des performances. Pendant le cycle de vie de la JSF Reference Implementation 1.2 de Sun (nommée Mojarradepuis la version 1.2_08, autour de 2008), pratiquement chaque version a été livrée avec des améliorations (majeures) de performances similaires à celles habituelles. (corrections de bugs mineurs.

Le seul inconvénient majeur de JSF 1.x (y compris la version 1.2) est l’absence de portée entre la demande et sessionscope, le soi-disant conversationscope. Cela obligeait les développeurs à gérer des éléments d'entrée masqués, des requêtes de base de données inutiles et/ou à abuser de la portée de la session chaque fois que l'on souhaitait conserver les données de modèle initiales dans la requête suivante afin de traiter correctement les validations, les conversions, les modifications de modèle et les invocations d'action. applications Web complexes. La douleur pourrait être atténuée en adoptant une bibliothèque tierce qui conserve les données nécessaires dans la requête suivante, telle que MyFaces Tomahawk<t:saveState> _ composant, JBoss Seam portée de la conversation et MyFaces Orchestra cadre de conversation.

Un autre inconvénient pour les puristes HTML/CSS est que JSF utilise le colon : en tant que caractère séparateur d’ID pour garantir le caractère unique 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 (création de 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 caractère \ pour échapper aux deux points dans les sélecteurs CSS, ce qui donne des sélecteurs laids et bizarres 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 puriste, lisez aussi Par défaut, JSF génère des identifiants inutilisables, qui sont incompatibles avec la partie css des standards web .

De plus, JSF 1.x n’a pas été livré avec les installations d’Ajax. Ce n’est pas vraiment un désavantage technique, mais à cause du battage médiatique du Web 2.0 au cours de cette période, cela est devenu un désavantage fonctionnel. Exadel était sur le point d'introduire Ajax4jsf, qui a été complètement développé au cours des années et qui est devenu l'élément central de la bibliothèque de composants de JBoss RichFaces . Une autre bibliothèque de composants a été livrée avec les pouvoirs Ajax intégrés, la plus connue étant ICEfaces .

À peu près à mi-parcours de la durée de vie de JSF 1.2, une nouvelle technologie d'affichage 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)

Ce fut 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é élargi avec des fonctionnalités permettant de créer des composants personnalisés à l'aide de XML pur (appelé composants composites ). Voir aussi Pourquoi Facelets est-il préférable à JSP en tant que langage de définition de vue à partir de JSF 2.0??

Les pouvoirs Ajax ont été introduits à la saveur de la <f:ajax> composant qui a beaucoup de similitudes avec Ajax4jsf. Les annotations et les améliorations de convention sur la configuration ont été introduites dans kill the verbose faces-config.xml file autant que possible. De plus, le caractère de séparation par défaut du conteneur d’appel d’identification : est devenu configurable, de sorte que les puristes HTML/CSS puissent respirer soulagés. Tout ce que vous avez à faire est de le définir comme init-param dans web.xml avec le nom javax.faces.SEPARATOR_CHAR et vous assurer que vous n'utilisez vous-même le personnage dans aucun identifiant client, tel que -.

Enfin et surtout, une nouvelle portée a été introduite, la vue scope. Il a éliminé un autre inconvénient majeur de JSF 1.x, comme décrit précédemment. Vous venez de déclarer le haricot @ViewScoped pour activer l’étendue de la conversation sans tracasser tous les moyens de conserver les données dans les requêtes (conversationnelles) suivantes. UNE @ViewScoped _ bean restera actif tant que vous soumettez et naviguez par la suite dans la même vue (indépendamment de l'onglet/de la fenêtre du navigateur ouvert!), de manière synchrone ou asynchrone (Ajax). Voir aussi Différence entre les étendues View et Request dans les beans gérés et Comment choisir l'étendue du bean correct?

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 obstacle. Le @ViewScoped échoue dans les gestionnaires d'étiquettes en raison d'un problème poulet-oeuf en état de sauvegarde partielle. Ceci est corrigé dans JSF 2.2 et rétroporté dans Mojarra 2.1.18. En outre, en transmettant des attributs personnalisés, tels que HTML5 data-xxx n'est pas supporté. Ce problème est résolu dans JSF 2.2 par la nouvelle fonctionnalité d’éléments/d’attributs passthrough. De plus, l'implémentation JSF de Mojarra a son propre ensemble de problèmes . Relativement nombreux sont liés au comportement parfois non intuitif de <ui:repeat> , le nouvelle implémentation de sauvegarde d'état partiel et le portée de flash mal implémentée . La plupart d'entre eux sont corrigés dans une version Mojarra 2.2.x.

Aux alentours de JSF 2.0, PrimeFaces a été introduit, basé sur jQuery et jQuery UI. C'est devenu la bibliothèque de composants JSF la plus populaire.

JSF 2.2 (mai 2013)

Avec l'introduction de JSF 2.2, HTML5 était utilisé comme mot à la mode même s'il était techniquement pris en charge dans toutes les versions plus anciennes de JSF. Voir aussi prise en charge de JavaServer Faces 2.2 et HTML5, pourquoi le XHTML est-il toujours utilisé . La nouvelle fonctionnalité la plus importante de JSF 2.2 est la prise en charge des attributs de composant personnalisés, ouvrant ainsi un monde de possibilités, telles que groupes de boutons radio personnalisés sans tablea .

Mis à part les bogues spécifiques à l'implémentation et certaines "petites choses ennuyantes" telles que l'incapacité d'injecter un EJB dans un validateur/convertisseur (déjà corrigé dans JSF 2.3), la spécification JSF 2.2 ne présente pas d'inconvénient majeur.

Composant MVC vs composant MVC

Certains pourraient penser que le principal inconvénient de JSF est qu’il permet très peu de contrôle précis sur le code HTML/CSS/JS généré. Ce n'est pas le propre de JSF, c'est simplement parce que c'est un framework basé sur des composants MVC, pas un framework basé sur des requêtes (actions)MVC. Si vous avez besoin de beaucoup de contrôle du code HTML/CSS/JS lorsque vous envisagez un framework MVC, vous ne devriez pas déjà vous intéresser à un framework MVC basé sur des composants, mais à un framework MVC basé sur des requêtes, tel que Spring MVC). . Il vous suffit de prendre en compte le fait que vous devrez écrire vous-même tout ce que vous voulez HTML/CSS/JS. Voir aussi Différence entre Request MVC et Component MVC .

Voir également:

• Quelle est la différence entre JSF, Servlet et JSP? (juste pour comprendre les bases)
• tilisation de JSF pour développer des mises en forme CSS sans tablea (un autre mythe sur JSF)
• JSF vs HTML/CSS/JS/jQuery simple (lorsque JSF est le mauvais choix)
• Modèles de conception dans les applications Web (illustre l'idéologie derrière MVC)

Answer 2

Après 5 ans de travail avec JSF, je pense pouvoir ajouter mes 2 centimes.

Deux inconvénients majeurs JSF:

1. Grande courbe d'apprentissage. JSF est complexe, c'est vrai.
2. Son composant nature. Le framework à base de composants tente de masquer la véritable nature du Web, qui s'accompagne de nombreuses complications et catastrophes (comme ne pas prendre en charge GET dans JSF dans presque 5 ans).
   IMHO cacher la requête HTTP/Réponse du développeur est une énorme erreur. D'après mon expérience, chaque infrastructure à base de composants ajoute une abstraction au développement Web et cette abstraction entraîne une surcharge inutile et une complexité accrue.

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

1. Par défaut, l'identifiant de l'objet est composé des identifiants de ses parents, par exemple form1: button1.
2. Pas de moyen facile de commenter un fragment de page incorrect. La balise <ui:remove> A besoin d’un contenu syntaxiquement correct, qui est quand même analysé.
3. Composants tiers de qualité médiocre, par exemple ne cochez pas la case isRendered() dans la méthode processXxx() avant de continuer.
4. Incorporer LESS & Sencha est difficile.
5. Ne joue pas bien avec REST.
6. Pas facile pour les concepteurs UX, car les composants prêts à l'emploi ont leurs propres styles CSS, qui doivent être écrasés.

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

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

Pour moi, c'est le principal inconvénient de JSF. IMHO JSF peut convenir à certains types d'applications (intranet, intensif en formulaires), mais dans la vie réelle web application, ce n'est pas une bonne solution.

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

Answer 3

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

1. JSF est un framework à base de composants. Cela comporte des restrictions inhérentes au respect du modèle composant.
2. AFAIK JSF ne prend en charge que POST, donc si vous voulez un GET quelque part, vous devez créer une servlet/JSP simple.
3. La plupart des composants essaient de fournir des abstractions sur des domaines tels que les bases de données relationnelles et le JavaScript frontal, et souvent, ces abstractions sont "fuyantes" et très difficiles à déboguer.
4. Ces abstractions peuvent constituer un bon point de départ pour un développeur junior ou pour une personne qui n'est pas à l'aise dans un domaine particulier (par exemple, le JavaScript frontal), mais qui sont très difficiles à optimiser en termes de performances, car plusieurs couches sont impliquées, et la plupart des utilisateurs les utilisant. avoir peu de compréhension de ce qui se passe sous le capot.
5. Les mécanismes de gabarit habituellement 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 code HTML/CSS que vous devrez passer une éternité à convertir.
6. Des choses comme les expressions EL ne sont pas vérifiées statiquement et que le compilateur et les IDE ne font pas un bon travail pour trouver des erreurs, vous allez donc vous retrouver avec des erreurs que vous devrez détecter au moment de l'exécution. Cela pourrait convenir à un langage dynamiquement typé tel que Ruby ou PHP, mais si je dois résister à la surabondance de l’écosystème Java, je demande à taper pour mon modèles.

Pour résumer: Le temps que vous gagnerez avec JSF, en évitant d’écrire le code JSP/servlet/bean, vous le passerez x10 pour le faire évoluer et faire exactement ce que vous voulez. faire.

Answer 4

Pour moi, le plus gros désavantage de JSF 2.0 est la courbe d’apprentissage non seulement de JSF, mais également des bibliothèques de composants que vous devez utiliser pour le rendre utile. Considérez le nombre impressionnant de spécifications et de normes que vous avez gérées 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 - quand vous ne pouvez pas comprendre ce qui se passe, vous devez ouvrir Firebug et voir. Pour cela, vous devez savoir ceci.
• CSS - Qu'on le veuille ou non. Ce n'est pas si grave et il y a au moins quelques outils de Nice.
• 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 de ce paquet. En dehors de cela, vous devez savoir comment vos Facelets sont transformés en XHTML ou autre.
• JSP (principalement pour que vous sachiez 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 le nom que vous voulez appeler.
• JSON - vous devriez le savoir même si vous ne l'utilisez pas.
• AJAX. Je dirais que JSF 2.0 fait un travail décent pour vous cacher cela, mais vous devez toujours savoir ce qui se passe.
• Le DOM. Et comment un navigateur l'utilise. Voir ECMAScript.
• Evénements DOM - un sujet à lui tout seul.
• JPA (Java Persistence Architecture), c’est-à-dire si vous souhaitez que votre application dispose d’une base de données back-end.
• Java lui-même.
• JSEE pendant que vous y êtes.
• La spécification CDI (Context Dependency Injection) et son interaction avec et est utilisée avec JSF 2.0
• JQuery - J'aimerais vous voir vous en passer.

Maintenant, une fois que vous en avez fini, vous pouvez vous mettre au travail 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
• Mesfaces
• ICEFaces
• EclipseLink (mon fournisseur JPA)
• Hibernate
• Souder

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

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

Donc - CECI IS RENDRE SIMPLE? Bien sûr, JSF 2.0 est "facile" tant que vous ne voulez que faire les pages Web les plus simples avec les interactions les plus simples.

En termes simples, JSF 2.0 est le mélange le plus compliqué et le plus encombrant de technologies collées existant actuellement dans l’univers logiciel. Et je ne peux penser à rien que je préférerais utiliser.

Answer 5

1. Les développeurs inexpérimentés créeront généralement des applications extrêmement lentes et le code sera vraiment moche et difficile à maintenir. Sa simplicité trompeuse au début, mais nécessite en fait un investissement en apprentissage si vous voulez écrire de bons programmes.
2. Au moins au début, vous serez souvent "bloqué" sur un problème et passerez plus de temps à lire des articles de balusc sur Internet qu'à travailler :) Après un moment, ce sera de moins en moins de cela, mais cela peut quand même être ennuyeux.
3. Encore plus gênant lorsque vous découvrez que le problème n'est pas dû à votre manque de connaissance/erreur, mais bien à 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 dans la version 4. Nous avons Primefaces qui est meilleur, 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 de Primefaces. Donc, je dirais que c'est un buggy mais que ça va mieux surtout après la version 2.2 qui a corrigé quelques problèmes avec spec. Framework en train de devenir plus mature mais toujours loin d’être parfait (peut-être mieux pour mes faces?).
4. Je ne le trouve pas particulièrement flexible. Souvent, si vous avez besoin de quelque chose de très très personnalisé et qu'aucun composant ne le fait, cela sera un peu pénible. Encore une fois, je parle du point de vue d'un développeur moyen - celui avec des délais, des tutoriels de lecture rapides et une recherche de stackoverflow en cas de blocage, car vous n'avez pas le temps d'apprendre comment cela fonctionne réellement :) 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 quelque chose que vous voulez :) Il faut faire attention en évaluant s'il vaut mieux créer son propre composant ou le composant existant à torturer. En fait, si vous créez quelque chose de vraiment unique, je ne recommanderais pas JSF.

En résumé, mes inconvénients seraient les suivants: complexité, progrès de développement peu rapides, 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 framework. D’autres pourraient avoir des opinions divergentes. Le mieux est donc de l’essayer pendant un moment pour voir si c’est pour vous (quelque chose de plus complexe - pas d’exemples naïfs - JSF brille vraiment ici :) IMHO: meilleur exemple d’utilisation pour JSF est une application métier, comme un CRM, etc.

Answer 6

"JSF générera le code HTML et le code JavaScript de la couche de visualisation que vous ne pouvez ni contrôler ni modifier sans entrer dans le code du contrôleur."

En fait, JSF vous donne la flexibilité, vous pouvez utiliser des composants standard/tiers ou créer vos propres composants, ce qui vous permet de contrôler totalement ce qui est rendu. C'est juste un xhtml dont vous avez besoin pour créer vos composants personnalisés avec JSF 2.0.

Answer 7

Nous avons développé un exemple de projet avec JSF (Il s’agissait d’une recherche de trois semaines et nous risquons de perdre certaines choses!)

Nous essayons d'utiliser core jsf, si un composant est nécessaire, nous avons utilisé 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 d’assistant en trois étapes. Chaque page comporte 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 corriger l'état de la vue JSF. L'état JSF sera corrompu lorsque vous incluez des pages via ajax l'une dans l'autre. Cela semble un bogue dans JSF et pourrait être corrigé dans les prochaines versions (pas dans la 2.3).
2. Le flux JSF ne fonctionne pas correctement avec ajax (ou nous ne pouvions pas le faire fonctionner!) Nous essayons d'utiliser le composant Assistant Primeface à la place, mais la validation du client ne semble pas prise en charge et signifie alors que ce n'était pas le standard de flux JSF standard.
3. Lorsque vous utilisez des composants jQuery tels que jqGird et que vous devez charger des résultats JSON, il vous 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 s'intégrera pas dans JSF.
4. Nous essayons de faire quelques scripts clients quand ajax complète par ajaxComplete et nous avons constaté que le PF 4 avait implémenté ses propres événements ajax. Nous avions quelques composants jQuery et nous devons changer leur code.

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

Nous résumons nos recherches comme suit:

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

Bien sûr, nous trouvons dans JSF de nombreuses fonctionnalités intéressantes qui peuvent s'avérer très utiles dans certains projets, alors tenez compte de vos besoins.

Veuillez vous reporter aux documents techniques de JSF pour examiner les avantages de JSF et, à mon avis, le plus gros avantage de JSF est le support COMPLET ET ÉNORME de @BalusC ;-)

Answer 8

Je ne suis pas du tout expert Java Server Faces. Mais, à mon humble avis, le principal inconvénient est qu'il est côté serveur. J'en ai assez d'apprendre et d'utiliser des frameworks de couche de présentation Web côté serveur comme ASP.NET Web Forms, ASP.NET MVC, Java Faces serveur, Struts, frameworks php et Ruby sur Rails. I dit au revoir à tous, et bonjour à Angularjs et à TypeScript, ma couche de présentation s'exécute sur le navigateur. Peu importe qu'elle soit servie par Windows IIS avec php ou ASP. NET, ou s’il est servi par un serveur Web Apache fonctionnant sous Linux, il me suffit de connaître un seul framework qui fonctionne partout.

Juste mes deux cents.

Answer 9

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

• Si vous pouvez utiliser des composants "standards", 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 Twitter bootstrap pour notre projet. (Pas bootstrap de primefaces)).
  • Maintenant, nos pages fonctionnent comme suit:
    • La page se charge.
    • L'utilisateur interagit avec un Primefaces doté de la fonctionnalité ajax
    • Les liaisons javascript de Bootstrap cassent
    • Nous utilisons du javascript supplémentaire pour tout relier

La promesse de JSF d'éviter d'écrire du javascript s'est traduite par l'écriture de plus de javascript que si nous n'avions pas utilisé Primefaces - et que javascript corrige ce que Primefaces a cassé.

C'est un temps perdu - à moins que vous n'utilisiez à nouveau du matériel "standard". Aussi vraiment moche (Primefaces) lorsqu’on doit travailler avec Selenium. Tout peut être fait, mais encore une fois, le temps est compté.

Evitez cela si vous travaillez avec une équipe de conception UX/et que vous avez besoin d'itérer rapidement l'interface utilisateur - vous pouvez gagner du temps en apprenant à écrire/écrire du code HTML directement - ou en regardant réactif/angulaire.

Answer 10

Pour moi, le plus gros inconvénient de JSF est la prise en charge insuffisante des pages générées par programmation (de manière dynamique).
Si vous souhaitez construire votre page (créer un modèle de composant de page) de manière dynamique à partir de Java. Par exemple, si vous travaillez sur le constructeur de page Web WYSIWYG. Documentation adéquate de ce cas d'utilisation Il existe de nombreux points où il faut expérimenter et le développement est assez lent.Beaucoup de choses ne fonctionnent pas comme prévu, mais en général, il est possible de le bidouiller.
La bonne chose est que ce n'est pas un problème de philosophie ou d'architecture de JSF. Ce n'est tout simplement pas assez élaboré (à ma connaissance).

JSF 2 a apporté Composites Composés qui devrait faciliter le développement de composants, mais leur support pour la construction dynamique (programmatique) est très médiocre. Si vous surmontez un processus compliqué et presque non documenté de construction dynamique de composants composites, vous découvrirez que si vous imbriquez quelques composants composites un peu plus profondément, ils cessent de fonctionner, lançant quelques exceptions.

Mais il semble que la communauté JSF est consciente de ces lacunes. Ils travaillent dessus comme vous pouvez le voir sur ces deux bugs
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.

Answer 11

JSF a de nombreux avantages, la question étant en désavantage, permettez-moi d'ajouter quelques points à ce sujet.

Sur un scénario pratique de mise en œuvre d'un projet Web avec une période 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 nécessaire à la courbe d’apprentissage initiale?

• Avez-vous suffisamment d’expertise dans votre équipe pour pouvoir passer en revue le JSF?
  produits produits par les développeurs?

Si votre réponse est "Non" pour les questions, vous risquez de vous retrouver dans une base de code non maintenable.

Answer 12

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 la plus élaborée en matière de couche de présentation et orientée composant fournie. Il est un peu lourd et incomplet par rapport aux solutions fournies par HybridJava.

Answer 13

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

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