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


234

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?

2
Franchement, nous devrions nous débarrasser de tous ces composants, Bean, "merde" et revenir au codage normal. Je ne veux pas d'un cadre épais qui va essayer de tout faire pour moi (et de le faire horriblement, je pourrais ajouter) et de m'éloigner de ce qui se passe réellement en dessous. Je recommanderais de jeter un œil à TypeScript et d'essayer de trouver des couches de code très fines qui fonctionnent avec cela et qui sont construites sur cela. JSF / PF et ses amis ont beaucoup de "fonctionnalités", mais vous devez vous déplacer sur la pointe des pieds et connaître le bon code d'attribut magique ou la disposition de l'arborescence pour faire ce que vous voulez, etc.
Andrew

Réponses:


464

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:


5
En ce qui concerne les étendues: dans Java EE 6, il est également possible d'utiliser une étendue qui étend les demandes à différentes vues. Il s'agit de la portée de conversation CDI. Bien que techniquement ne faisant pas partie de JSF proprement dit, il s'intègre si bien avec JSF qu'il ressemble à une installation JSF native.
Arjan Tijms

3
Néanmoins, ui: repeat doit être corrigé, et les bogues avec h: dataTable + ajax imbriqués sont pathétiques après plus d'un an de versions. Vraiment dommage, parce que sinon les deux problèmes que je recommande JSF 2.0 à tout le monde comme la solution pour tout le développement d'applications Web.
fdreger

1
Belle réponse, mais je pense manquer quelques arguments sur les tests. Les JSF sont difficiles à tester. ASP.NET MVC sont prêts pour TDD.
Guaido79

14
J'ai 20 ans d'expérience JAVA / WEB et je refuse tous les projets qui utilisent JSF comme moi et s'il vous plaît ne vous sentez pas offensé, JSF est le plus horrible de tous les frameworks. Il viole toutes les règles d'abstraction qui mélangent css, html et java. Les progrès dans les projets JSF sont ridicules par rapport, par exemple, à un projet ExtJS avec Spring MVC. La maintenance dans JSF est horrible et simple, sinon les problèmes simples sont un clusterf *** complet dans JSF. D'après mon expérience, n'utilisez PAS JSF. Standard ou non, c'est une mauvaise norme qui ne devrait même pas être une norme. Essayez VAADIM ou portillon ou ExtJS.
Lawrence

1
Le gros inconvénient est son intégration médiocre dans Eclipse IDE sans prise en charge de la refactorisation, mauvaise prise en charge de la fragmentation Web, mauvaise intégration du serveur, non click and go to component or include, pas de graphique de dépendance des composants / balises et pas de menu pour les balises propres ou tierces. Je passe beaucoup de temps à effectuer des recherches à l'échelle du projet juste pour comprendre où le composant ou la fonction x est utilisé.
djmj

56

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.


4
+1 web a été conçu pour être apatride, bon ou mauvais, personne ne peut le changer (et il n'y a aucune raison à cela!)
Alireza Fattahi

1
Il peut sûrement gérer de grands sites irctc.co.in est en jsf qui est le plus grand site de commerce électronique en Inde. . . mais oui avec JSF vous n'avez pas beaucoup de contrôle sur l'interface utilisateur qui est générée.
Nirbhay Mishra du

2
Pourriez-vous définir ce qu'est un real-life web application? JSF cache également la nature de la demande / réponse, ce qui pourrait être vrai, mais c'est la responsabilité des programmeurs de savoir ce qui se passe vraiment sous les couvertures. Si vous ne savez pas comment HTTP fonctionne, apprenez-le avant JSF ou tout autre framework.
Xtreme Biker du

25

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.


15
Il fait clairement référence à JSF 1.x et ignore le fait qu'il s'agit d'un framework MVC basé sur les composants tout en ayant un framework MVC basé sur les requêtes.
BalusC

17
1) Si vous ne voulez pas de MVC basé sur des composants, pourquoi envisagez-vous JSF? 2) Plus depuis JSF 2.0. 3) La partie domaine est fausse. Aucun des composants JSF ne fait cela. Les bogues JS dans l'impl, eh bien, y en a-t-il? Mojarra est assez mature pour l'instant. 4) JSF a en effet une courbe d'apprentissage abrupte, mais cela ne la rend pas nécessairement mauvaise. 5) Les éditeurs visuels sont de toute façon épiques. Encore une fois, le MVC basé sur les composants vs sur la question. 6) C'est une question de bon outil, pas de JSF. Eclipse a des plugins et IntelliJ Ultimate le fait immédiatement.
BalusC

19
@BalusC pardonne-moi si je semble irrespectueux, mais la question n'est pas JSF 1 contre JSF 2, et votre réponse qui se lit comme "l'histoire de JSF" est sans importance. De plus, votre affirmation selon laquelle JSF n'a «aucun inconvénient grave» ne reconnaît pas le principe d'ingénierie fondamental selon lequel tous les outils ont leurs limites et leur domaine où ils exécutent d'autres solutions.
Kay Pale

24
Je considère que l'histoire est très pertinente pour savoir comment JSF 2.0 a éliminé les anciens inconvénients car ce sont exactement ces inconvénients qui ont donné à JSF une image négative de l'histoire. Quant au reste, eh bien nous avons juste un désaccord.
BalusC

5
Honnêtement, je ne comprends pas pourquoi vous citez «basé sur les composants» comme un inconvénient. C'est comme dire "l'inconvénient de http est qu'il est sans état". Cela devrait être modifié. Bien sûr, parfois le fait que http soit apatride est nul, mais parfois c'est exactement pourquoi nous l'utilisons. La même chose avec JSF.
arg20

19

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.


42
La plupart de cela s'applique également à tout autre cadre Web. Comment est-ce la faute de JSF d'avoir à connaître jQuery pour être productif avec lui?
Adrian Grigore

8
JSF est juste la couche de vue. Maintenant, vous semblez sous-entendre qu'avec d'autres technologies, vous n'avez pas besoin de tout savoir, pouvez-vous s'il vous plaît nous montrer laquelle?
arg20

Bien que ces technologies soient open source, elles sont fortement liées aux organisations privées qui les maintiennent. Peut-être que le mot propriétaire ne vous convient pas, mais ils pourraient tout aussi bien l'être.
AlanObject

Je voudrais en venir à la défense de @AlanObject ... Je pense qu'il a peut-être voulu dire en disant propriétaire, comme dans le fait que tous les projets open source sont en fait "possédés" par quelqu'un. Prenons par exemple MySQL. Ils ont vraiment marqué gros lorsqu'ils ont vendu à Oracle. Comme aussi, Java !! Ainsi, de nombreux projets open source, même s'ils sont ouverts pour être utilisés / modifiés / apportés, sont toujours soumis aux spécifications inhérentes à chaque outil open source que vous utilisez actuellement. Parce qu'il est "possédé" par quelqu'un. Vous ne pouvez pas ignorer les spécifications nécessaires à leur utilisation. Ce n'est pas une mauvaise chose :)
CA Martin

13
  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 ...


11

"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.


11

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.


Et n'oubliez pas que chaque framework côté client a besoin d'un homologue côté serveur pour la sécurité, la validation, etc.
Kukeltje

1
Oui bien sûr. Non seulement pour la sécurité et la validation, mais pour le backend et la logique commerciale. Tout cela grâce à des services Web reposants. Le point ici est d'éviter de générer du html côté serveur.
Jesús López

10

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 ;-)


6

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.


6

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.


Non, votre choix de combiner bootstrap et primefaces vous a fait écrire plus de javascript que nécessaire. Soit utiliser des bootfaces ou une réactivité PF. Et comment est-il moche de travailler avec du sélénium? Veuillez développer.
Kukeltje du

Voici un exemple de sélénium. <input type="checkbox" name="versionsTab" value="version1"> Case à cocher HTLM : case à cocher Primefaces: <div class="ui-chkbox ui-widget"> <div class="ui-helper-hidden-accessible"> <input type="checkbox" name="datasetForm:tabView:versionsTable_checkbox"> </div> <div class="ui-chkbox-box ui-widget ui-corner-all ui-state-default"> <span class="ui-chkbox-icon ui-c"></span> </div> </div> Selenium n'a pas pu trouver la case à cocher réelle qui s'est cachée. par exemple, je pourrais le trouver avec des sélecteurs / codage / etc, mais l'équipe QA pas aussi technique ne pouvait pas
rprasad

1
Vous voulez dire le nom concaténé? La beauté est dans l'oeil de celui qui regarde. Si vous apprenez un petit xpath, il peut être contourné sans trop de problèmes. Et ce n'est pas spécifiquement une chose PF. Et en ce qui concerne les choses de l'équipe de conception. Laissez-les concevoir le modèle et, pour le reste, respectez les directives jquery-ui. A parfaitement fonctionné pour nous ...
Kukeltje

J'ai rejoint le projet plus tard, mais des problèmes similaires à cette présentation où le projet a commencé avec des bootfaces mais avait vraiment besoin d'un bootstrap complet (+ primefaces): oracleus.activeevents.com/2014/connect/…
rprasad

L'application fonctionne - Primefaces n'est en aucun cas un bouchon d'exposition - mais il y a (et continue d'être) un temps supplémentaire. Par exemple, en particulier par rapport à des collègues utilisant des frameworks tels que Play et Django. (Je suis d'accord avec votre autre point, je pense que QA devrait pouvoir utiliser xpath si nécessaire - je leur ai donné des scripts de travail)
rprasad

1

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.


0

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".


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.