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

Question

J'ai vu hier une présentation sur Java Server Faces 2.0 qui avait l'air vraiment impressionnant, même si je suis actuellement un développeur ASP.NET MVC heureux / jQuery. Ce qui m'a plu le plus JSF est l'énorme quantité de composants d'interface utilisateur AJAX-Activés qui semblent faire du développement beaucoup plus rapide qu'avec ASP.NET MVC, en particulier sur les sites AJAX-lourds. Les tests d'intégration avait l'air très bien aussi.

, je voudrais Depuis la présentation ne fait que souligner les avantages du JSF pour entendre de l'autre côté aussi.

Alors mes questions sont:

• Quels sont les principaux inconvénients de Java Server Faces 2.0?
• Ce qui pourrait faire un développeur de JSF ASP.NET MVC envisager d'utiliser au lieu de JSF?

Answer 1

JSF 2.0 inconvénients? Honnêtement, en dehors de la courbe d'apprentissage abrupte par rapport lorsque vous ne disposez pas d'une solide connaissance de base sur développement Web de base (HTML / CSS / JS, côté serveur par rapport côté client, etc.) et base API Java Servlet (demande / réponse / session, expédition / redirection, etc.), aucun inconvénient sérieux vient à l'esprit. JSF dans sa version actuelle a encore besoin de se débarrasser de l'image négative qu'il a gagné au cours des premiers siècles, au cours de laquelle il y avait plusieurs inconvénients graves.

JSF 1.0 (Mars 2004)

Ce fut la version initiale. Il a été encombré de bugs dans les deux domaines clés et de performance que vous ne voulez pas savoir. Votre webapplication ne fonctionne pas toujours comme vous vous intuitivement attendre. Vous en tant que développeur courriez dur en pleurant.

JSF 1.1 (mai 2004)

Ce fut la version bugfix. La performance était pas encore beaucoup améliorée. Il y avait aussi un inconvénient majeur: vous ne pouvez pas HTML en ligne dans la page JSF parfaitement. Tous vanilles HTML get rendu avant l'arborescence des composants JSF. Vous devez envelopper tous vanilles dans les balises <f:verbatim> afin qu'ils s'inclus dans l'arborescence des composants JSF. Bien que ce soit selon le cahier des charges, ce qui a reçu beaucoup de critiques. Voir aussi A.O. JSF / Facelets: pourquoi 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 sortie du nouveau chef d'équipe de développement JSF par Ryan Lübke. La nouvelle équipe a fait beaucoup de bon travail. Il y avait aussi des changements dans les spécifications. Le principal changement est l'amélioration du traitement de la vue. Non seulement JSF entièrement détaché de JSP, donc on pourrait utiliser une technologie de vue différent de JSP, mais également aux développeurs autorisés à Inline HTML vanilles dans la page JSF sans hassling avec des balises <f:verbatim>. Un autre axe majeur de la nouvelle équipe a été l'amélioration des performances. Pendant toute la durée de la mise en œuvre JSF Sun référence 1.2 (qui a été le nom de code Mojarra depuis la construction 1.2_08, autour de 2008), pratiquement tous les construire mais j'ai livré avec (grandes) amélioration de la performance à côté des corrections de bugs habituels (mineures) .

L'inconvénient grave que 1.x JSF (y compris 1.2) est l'absence d'un champ entre le demande et Session portée, le soi-disant la conversation portée. Ce développeurs forcés de tracas 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 ultérieure afin de traiter avec succès les validations, les conversions, les changements de modèle et invocations d'action dans plus webapplications complexes. La douleur peut être adoucie par l'adoption d'une bibliothèque 3ème partie qui conserve les données nécessaires à la demande ultérieure comme MyFaces Tomahawk composant <t:saveState>, champ de conversation JBoss Seam et MyFaces Orchestra cadre de conversation.

Un autre inconvénient de HTML / CSS puristes est que JSF utilise le : du côlon comme séparateurs d'identité pour garantir l'unicité de l'élément HTML id dans la sortie HTML généré, en particulier quand un composant est réutilisé plusieurs fois dans la vue (texturant, composants itération, etc.). Parce que c'est un caractère illégal dans les identificateurs CSS, vous devez utiliser le \ pour échapper au i du côlonn sélecteurs CSS, ce qui sélecteurs laid et regarder bizarres comme #formId\:fieldId {} ou même #formId\3A fieldId {}. Voir aussi Comment utiliser JSF élément HTML ID généré avec deux points « : » dans les sélecteurs CSS Toutefois, si vous n'êtes pas un puriste, lisez aussi par défaut, JSF génère ids inutilisables, qui sont incompatibles avec une partie css des standards du web .

En outre, 1.x JSF n'a pas été livré avec des installations Ajax hors de la boîte. Pas vraiment un inconvénient technique, mais en raison du battage médiatique Web 2.0 au cours de cette période, il est devenu un désavantage fonctionnel. Exadel a été tôt pour introduire Ajax4jsf, qui a été soigneusement mis au point au cours des années et est devenu la partie centrale de RichFaces JBoss bibliothèque de composants. Un autre des bibliothèques de composants ont été livrés avec Ajax pouvoirs builtin aussi bien, le bien connu étant ICEfaces .

A propos de la durée de vie à mi-chemin JSF 1.2, une nouvelle technologie d'affichage à base de XML a été introduit: composants composites ). Voir aussi Pourquoi Facelets est préféré sur JSP comme la langue de définition de la vue à partir JSF2.0 partir?

Ajax pouvoirs ont été introduits dans la saveur du composant <f:ajax> qui a beaucoup de similitudes avec Ajax4jsf. Les annotations et les améliorations convention-sur-configuration ont été introduites pour le fichier faces-config.xml bavard autant que possible. En outre, le conteneur nom par défaut ID séparateur : est devenu configurable, les puristes HTML / CSS respirais soulagé. Tout ce que vous devez faire est de le définir comme init-param en web.xml avec le nom javax.faces.SEPARATOR_CHAR et veiller à ce que vous n'utilisez pas le caractère vous partout dans le client ID de, comme -.

Last but not least, a introduit un nouveau champ d'application, le vue portée. Il a éliminé un autre inconvénient majeur de 1.x JSF comme décrit précédemment. Vous déclarez que la @ViewScoped de haricots pour permettre au champ de conversation sans harcelaient toutes les façons de conserver les données dans les demandes ultérieures (conversation). Un grain de @ViewScoped vivra aussi longtemps que vous soumettez ensuite et en accédant à la même vue (indépendamment de l'onglet du navigateur ouvert / fenêtre!), De manière synchrone ou asynchrone (Ajax). Voir aussi entre Voir et la portée de la demande dans les haricots gérés et Comment choisir le champ de haricot droit?

Bien que pratiquement tous les inconvénients de 1.x JSF ont été éliminés, il y a des bugs spécifiques JSF 2.0 qui pourrait devenir un Showstopper. attributs comme le data-xxx HTML5 n'est pas pris en charge. Ce problème est résolu dans JSF 2.2 par de nouveaux éléments intercommunication / attributs caractéristiques. en outre, la mise en œuvre du JSF Mojarra a son propre ensemble de problèmes . relativement beaucoup d'entre eux sont liés à la balise parfois le comportement de unintuitive <ui:repeat>, nouvelle mise en œuvre partielle sauvegarde de l'état et flash portée mal mis en œuvre . La plupart d'entre eux sont fixés dans une version 2.2.x Mojarra.

Autour du temps JSF 2.0, PrimeFaces a été introduit, basé sur jQuery et jQuery UI. Il est devenu la plus bibliothèque de composants JSF populaire.

JSF 2.2 (mai 2013)

Avec l'introduction de JSF 2.2, HTML5 a été utilisé comme mot à la mode même si cela était techniquement juste pris en charge dans toutes les versions de JSF plus. Voir aussi JavaServer Faces 2.2 et support HTML5, pourquoi est-XHTML encore utilisé . Le plus important nouvelle fonctionnalité JSF 2.2 est le support pour les attributs de composants personnalisés, l'ouverture par la présente un monde de possibilités, telles que sur mesure groupes de boutons radio tableless.

En dehors des bugs spécifiques de mise en œuvre et des « ennuyeux petites choses », comme l'incapacité d'injecter un EJB dans un validateur / convertisseur (déjà fixé dans JSF 2.3), il n'y a pas des inconvénients très importants dans la spécification JSF 2.2.

composants à base MVC vs demande en fonction MVC

Certains peuvent opter que l'inconvénient majeur de JSF est qu'il permet très peu de contrôle grains fins sur le HTML / CSS / JS généré. Ce n'est pas JSF propre, qui est juste parce qu'il est un composante framework MVC, pas demande (action) en fonction framework MVC. Si un haut degré de contrôle du HTML / CSS / JS est votre principale exigence lors de l'examen d'un framework MVC, alors vous devriez déjà pas à la recherche dans un cadre composant à base de MVC, mais à une demande fondée framework MVC comme Spring MVC . Vous avez seulement besoin de prendre en compte le fait que vous devez écrire tout ce que HTML / CSS / JS boilerplate vous. Voir aussi la différence entre demande MVC et le composant MVC .

Voir aussi:

• Quelle est la différence entre JSF, Servlet et JSP? (juste pour comprendre les bases)
• En utilisant JSF pour développer mises en page CSS tableless (un autre mythe au sujet de JSF)
• JSF vs simple HTML / CSS / JS / jQuery (quand 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 que je peux ajouter mes 2 cents.

Deux JSF majeur inconvénients :  

  
1. grande courbe d'apprentissage. JSF est complexe, qui est tout simplement vrai.   
2. La composante nature. cadre fondé sur les composants essaie de cacher la vraie nature du Web, qui est livré avec une énorme quantité de complications et les catastrophes (comme ne pas soutenir GET JSF depuis près de 5 ans).  
   à mon humble avis cacher requête HTTP / réponse du développeur est une énorme erreur. D'après mon expérience, chaque cadre à base de composants ajoute abstraction au développement Web, et que les résultats d'abstraction des frais généraux et plus complexes inutiles.  

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

 
1. Par défaut ID de l'objet est composé des ids de ses parents, par exemple form1: button1.  
2. pas facile de mettre en commentaire le fragment de la page incorrecte. Tag <ui:remove> a besoin de contenu syntaxiquement correct qui est analysé de toute façon.   
3. faible qualité composants 3ème partie qui par exemple ne pas vérifier isRendered() à l'intérieur méthode processXxx() avant de continuer.  
4. LESS & Sencha Incorporating est difficile.  
5. ne joue pas bien avec le repos.  
6. Pas si facile pour les concepteurs UX, parce que les composants prêts à l'emploi ont leurs propres styles CSS, qui ont besoin d'être remplacés.

Ne vous méprenez pas. En tant que JSF-cadre composant dans la version 2 est vraiment bon, mais il est encore à base de composants, et sera toujours ...

S'il vous plaît jeter un oeil à la faible popularité de la tapisserie, Wicket et faible enthousiasme des développeurs expérimentés JSF (ce qui est encore plus significatif). Et pour le contraste, jetez un oeil à la réussite de Rails, Grails, Django, Play! Cadre -. Tous sont basés sur l'action et ne pas essayer de cacher du programmeur true demande / réponse et nature sans état du web

Pour moi grand inconvénient de JSF est tout. À mon humble avis JSF pouvez convient un certain type d'applications (intranet, formes intensives), mais pour la vie réelle Web application, il est pas une bonne façon d'aller.

il aide quelqu'un l'espoir avec ses / ses choix qui concerne la fin de l'avant.

Answer 3

Quelques inconvénients qui apparaissent à l'esprit:

1. JSF est un cadre à base de composants. Cela a des restrictions inhérentes qui ont à voir avec l'obéissance à la -Modèle composant.
2. JSF ne supporte que AFAIK POST, donc si vous voulez un endroit GET vous avez faire une servlet simple / JSP.
3. La plupart des composants tentent de fournir des abstractions sur des domaines tels que bases de données relationnelles et frontal JavaScript, et beaucoup de temps ceux-ci abstractions sont "leaky" et très difficile à déboguer.
4. Ces abstractions pourrait être un bon point de départ pour un développeur junior ou quelqu'un mal à l'aise avec un domaine particulier (par exemple JavaScript front-end), mais sont très difficiles à optimiser la performance, car il y a plusieurs couches impliquées, et la plupart des gens que les utiliser ont peu de compréhension de ce qui se passe sous le capot.
5. Les mécanismes structurants qui sont habituellement utilisés avec JSF n'a rien à voir avec la façon dont web Desigers travail. Les éditeurs WYSIWYG pour JSF sont primitifs et dans tous les cas, votre concepteur vous donnera HTML / CSS que vous devrez passer les âges convertir.
6. Des choses comme les expressions EL ne sont pas vérifiées et statiquement à la fois le compilateur et IDEs ne sont pas fait un bon travail à des erreurs de trouver, de sorte que vous finirez avec des erreurs que vous aurez à prendre à l'exécution. Cela pourrait être bien pour langage typé dynamiquement comme Ruby ou PHP, mais si je dois résister à la météorisation pure de l'écosystème Java, je demande la saisie de mes modèles.

Pour résumer: Le temps que vous économiserez avec JSF, d'éviter d'écrire la page JSP / servlet / haricot code passe-partout, vous aurez dépensé x10 pour le rendre échelle et faire exactement ce que vous veux faire.

Answer 4

Pour moi, le plus grand inconvénient de JSF 2.0 est la courbe d'apprentissage non seulement du JSF, mais les bibliothèques de composants que vous devez utiliser pour obtenir de faire un travail utile. Considérons le nombre impressionnant de spécifications et les normes que vous avez affaire avec vraiment être 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 savoir.
• CSS - Qu'on le veuille ou non. Il est vraiment pas si mal et il y a quelques bons outils là-bas au moins.
• XML -. JSF sera probablement le premier endroit où vous utilisez les espaces de noms à ce degré
• Servlet Specification. Tôt ou tard, vous obtiendrez en appelant des méthodes dans ce package. Mis à part que vous devez savoir comment votre Facelets transformé en XHTML obtient ou autre.
• JSP (surtout si vous savez pourquoi vous n'avez pas besoin dans JSF)
• JSTL (encore une fois, la plupart du temps pour faire face au cadre de l'héritage)
• Expression Language (EL) dans ses diverses formes.
• ECMAScript, JavaScript, ou tout ce que vous voulez l'appeler.
• JSON -. Vous devriez savoir même si vous ne l'utilisez pas
• AJAX. Je dirais JSF 2.0 fait un travail décent de cacher cela de vous, mais vous devez toujours savoir ce qui se passe.
• Le DOM. Et comment un navigateur utilise. Voir ECMAScript.
• Événements DOM -. Un sujet par lui-même
• Java Persistence Architecture (JPA) qui est si vous voulez que votre application pour avoir une base de données de fin arrière.
• Java lui-même.
• JSEE pendant que vous y êtes.
• Le contexte de dépendance spécification d'injection (CDI) et la façon dont elle se heurte à et est utilisé avec JSF 2.0
• JQuery -. Je voudrais te voir en passer

Maintenant, une fois que vous avez terminé que vous pouvez obtenir avec les spécifications propriétaires, à savoir les bibliothèques de composants et bibliothèques du fournisseur que vous prendrez le long du chemin:

• PrimeFaces (ma bibliothèque de composants de choix)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (mon fournisseur JPA)
• Mise en veille prolongée
• Weld

Et ne pas oublier le récipient! Et tous ces fichiers de configuration:

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

- CE REND FACILE? Bien sûr, JSF 2.0 est « facile » aussi longtemps que tout ce que vous voulez faire est la plupart des pages Web de base avec les interactions les plus simples.

En termes simples, JSF 2.0 est le méli-mélo le plus compliqué et lourd des technologies entrecollées comme cela existe dans l'univers du logiciel aujourd'hui. Et je ne peux pas penser à tout ce que je préfère utiliser.

Answer 5

1. développeurs inexpérimentées généralement créer des applications qui sont très lent et le code sera vraiment laid et difficile à maintenir. Son simple trompeusement pour commencer, mais exige en fait un investissement dans l'apprentissage si vous voulez écrire de bons programmes.
2. Au moins au début, vous souvent « coincé » sur un problème et va passer plus de temps à lire les messages de balusc sur Internet que de travailler en fait :) Après un certain temps, il sera de moins en moins, mais il reste peut être gênant .
3. Encore plus ennuyeux quand vous découvrez que le problème ne tient pas à vous le manque de connaissances / erreur, mais en fait un bug. Mojarra était (est?) Assez bogué, et une autre couche de composants ajoute encore plus de problèmes. Richfaces était le plus grand morceau de logiciel merde jamais écrit :) Je ne sais pas comment il est maintenant sur la version 4. Nous avons Primefaces ce qui est mieux, mais encore, vous rencontrez des bogues ou le manque de fonctionnalités en particulier avec des composants plus exotiques. Et maintenant, vous devrez payer pour les mises à jour Primefaces. Je dirais donc sa poussette, mais ça devient mieux surtout après la version 2.2 a corrigé quelques problèmes avec les spécifications. Cadre plus aboutis, mais encore loin d'être parfait (MyFaces peut-être mieux?).
4. Je ne trouve pas particulièrement flexible. Souvent, si vous avez besoin quelque chose de très très personnalisé et il n'y a pas de composants qui le fait - ce sera un peu douloureux. Encore une fois je parle du point de vue des développeurs moyen - celui des délais, des tutoriels de lecture rapide, et la recherche stackoverflow quand rester coincé parce que pas le temps d'apprendre comment il fonctionne vraiment :) Souvent, certains composants semble avoir « presque » ce dont vous avez besoin, mais pas exactement et parfois vous pourriez passer trop de temps pour lui faire faire quelque chose que vous voulez :) besoin d'être prudent dans l'évaluation si son mieux pour créer votre propre ou de torture 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:. La complexité, pas très lisse progrès du développement, buggy, inflexible

Bien sûr, il y a des avantages aussi, mais ce n'est pas ce que vous avez demandé. Quoi qu'il en soit que mon expérience avec d'autres cadres pourraient avoir des opinions différentes, donc la meilleure façon est d'essayer juste pendant un certain temps pour voir si son pour vous (juste quelque chose de plus complexe - exemples pas naïfs - JSF brille vraiment là :) mon humble avis le meilleur des cas d'utilisation pour JSF est des applications d'entreprise, comme ... etc CRMs

Answer 6

"JSF sortie View-couche HTML et JavaScript que vous ne pouvez pas contrôler ou changer 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 votre propre que vous avez le plein contrôle sur ce qui est rendu. Il est juste un xhtml dont vous avez besoin pour créer vos composants personnalisés avec JSF 2.0.

Answer 7

Nous avons mis au point un exemple de projet avec JSF (Il était une recherche de trois semaines afin que nous puissions avoir lose certaines choses!)

Nous essayons d'utiliser jsf noyau, si un composant est nécessaire, nous avons utilisé PrimeFaces.

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

Le site a deux usecases:

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

Nous avons constaté que:

1. Vous devez utiliser des hacks de omniFaces pour faire l'état d'affichage JSF fixe. L'état de JSF sera corrompu lorsque vous incluez les pages via ajax dans l'autre. Cela semble un bogue dans JSF et peut être fixé sur les prochaines versions (pas 2.3).
2. Le flux JSF ne fonctionne pas correctement avec ajax (ou nous ne pouvions pas le faire fonctionner!) Nous essayons d'utiliser à la place composant Assistant de primeface mais la validation du client ne semble pas pris en charge et dire alors qu'il n'était pas standard standard de débit JSF.
3. Lorsque vous utilisez certains composants comme jQuery jqGird, et vous devez charger les résultats JSON, il vous est conseillé d'utiliser servlet pur, le JSF ne fera rien pour vous. Donc, si vous utilisez ce type de composants, votre conception ne rentre pas dans JSF.
4. Nous essayons de faire des scripts clients lorsque ajax complet par ajaxComplete et nous avons trouvé que le PF 4 a mis en place ses propres événements ajax. Nous avons eu quelques composants de jQuery et nous avons besoin de changer leur code.

Si vous modifiez l'exemple ci-dessus à un non Ajax projet (ou au moins projet moins ajax) vous ne serez pas beaucoup face de dessus questions.

Nous résumons nos recherches:

  

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

Bien sûr, nous trouvons beaucoup de fonctionnalités intéressantes dans JSF qui peut être très utile dans certains projets, alors pensez à vos besoins du projet.

S'il vous plaît se référer à des documents techniques JSF aux avantages examen JSF, et à mon avis le plus grand avantage de JSF, est le support complet et immense de @BalusC; -)

Answer 8

Je ne suis pas Java Server Faces à tous les experts. Mais à mon humble avis le principal inconvénient est que son côté serveur. Je suis fatigué d'apprendre et d'utiliser des cadres de la couche de présentation Web côté serveur comme ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, framework PHP et Ruby sur les cadres de rails. Je l'ai dit au revoir à tous, et je dis bonjour à AngularJS et tapuscrit. Ma couche de présentation fonctionne sur le navigateur. Je n'a pas d'importance si elle est servie par Windows exécutant IIS PHP ou ASP.NET, ou si elle est desservie par un serveur Web Apache fonctionnant sous Linux. Je viens besoin d'apprendre un seul cadre qui fonctionne partout.

Juste mes deux cents.

Answer 9

Pour moi, le plus grand défaut de JSF est un mauvais support pour les pages générées dynamiquement (par programmation).
Si vous voulez construire votre page (créer modèle de composant page) dynamiquement à partir du code java. Par exemple, si vous travaillez sur le constructeur de page web WYSIWYG. Une documentation adéquate de ce cas d'utilisation en général pas disponible. Il y a beaucoup de points où vous avez à expérimenter et le développement est calme lent. Beaucoup de choses ne fonctionnent pas comment on peut s'y attendre. Mais généralement son bidouille possible, il en quelque sorte.
Bonne chose est que ce n'est pas problème dans la philosophie ou de l'architecture du JSF. Il est tout simplement pas assez élaboré (pour autant que je sache).

JSF 2 a combiné des composants composites qui devrait faire le développement de composants facile, mais leur soutien à la construction dynamique (programmatique) est très pauvre. Si vous surmontez calme compliqué et processus presque sans papier de construction dynamique composite des composants, vous découvrirez que si vous imbriquer quelques composants composites peu plus, ils arrêtent de travailler, jeter quelques exceptions.

Mais il semble que la communauté JSF est au courant de ces lacunes. Ils travaillent sur ce que vous pouvez voir à partir de ces deux bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Situation devrait être mieux avec JSF 2.2 au moins si nous parlons de la spécification.

Answer 10

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

• Si vous pouvez utiliser des composants « sur l'étagère », je suppose que ce n'est pas terrible.
• Cependant, il ne joue pas bien, dès que vous sortez et besoin UIs personnalisés. - Par exemple, nous avions besoin d'utiliser le bootstrap de Twitter pour notre projet. (Non primefaces bootstrap).
  • Maintenant nos pages fonctionnent comme suit:
    • charges de page.
    • l'utilisateur interagit avec un Primefaces qui a ajax fonctionnalité
    • La rupture des liaisons javascript Bootstrap
    • Nous courons javascript supplémentaire pour tout retirage

La promesse de JSF pour éviter d'écrire javascript transformé en écrit plus javascript que nous aurions sinon en utilisant Primefaces -. Et que le javascript pour corriger c'est des pauses Primefaces

Il est un puits de temps - à moins que vous utilisez à nouveau « sur l'étagère » des choses. Aussi vraiment laid (Primefaces) lorsqu'ils doivent travailler avec Sélénium. Il peut être fait - mais encore une fois -. Il y a seulement beaucoup de temps

éviter absolument si vous travaillez avec un UX / équipe de conception et à itérer rapidement sur l'interface utilisateur - vous pouvez gagner du temps en apprenant jquery / écriture HTML droite - ou regardant réagissez / angulaire.

Answer 11

JSF présente de nombreux avantages, être question sur les désavantages laissez-moi ajouter quelques points là-dessus.

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

• Avez-vous suffisamment de membres supérieurs dans votre équipe qui peut suggérer le meilleur des contrôles appropriés pour 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 le JSF
  choses produit par les développeurs?

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

Answer 12

JSF n'a qu'un seul inconvénient:. Avant de commencer le développement, vous devez comprendre clairement le développement web « JSF », java noyau et l'architecture de l'extrémité avant

De nos jours « nouveaux » cadres JavaScript juste essayer de copier / coller le modèle à base de composants « JSF ».

Answer 13

Parmi tous les cadres « mainstream » tels que Spring MVC, Wicket, tapisserie, etc., le JSF de Java EE avec ses composants composites est la présentation de la couche et la technologie des composants axée sur la plus élaborée fourni. Il est un peu encombrant et incomplet de par rapport aux solutions fournies par HybridJava.