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

hier, J'ai vu une présentation sur Java Server Faces 2.0 qui semblait vraiment impressionnante, même si je suis actuellement un heureux ASP.NET développeur MVC / jQuery. Ce que J'ai le plus aimé chez JSF, c'est l'énorme quantité de composants D'interface AJAX qui semblent accélérer le développement. ASP.NET MVC, en particulier sur les sites AJAX-lourds. Les tests d'intégration avaient l'air très bien aussi.

puisque la présentation ne mettait l'accent que sur les avantages du JSF, j'aimerais entendre sur l'autre côté.

donc mes questions sont:

  • Quels sont les principaux inconvénients de Java Server Faces 2.0?
  • Qu'est-ce qui pourrait amener un développeur JSF à envisager d'utiliser ASP.NET MVC au lieu de JSF?
226
demandé sur Adrian Grigore 2010-09-02 08:54:36
la source

13 ответов

JSF 2.0 inconvénients? Honnêtement, mis à part la courbe d'apprentissage relativement raide quand vous n'avez pas une connaissance de base solide sur développement web de base (HTML/CSS/JS, côté serveur versus côté client, etc) et le API Java Servlet de base (demande/réponse/session, redirection/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 acquise au cours de la l'âge précoce, au cours de laquelle il y avait plusieurs inconvénients graves.

JSF 1.0 (mars 2004)

il s'agit de 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 l'aviez prévu intuitivement. En tant que promoteur, tu t'enfuirais en pleurant.

JSF 1.1 (May 2004)

C'était la version bugfix. Le le rendement n'a pas encore été beaucoup amélioré. Il y avait aussi un inconvénient majeur: vous ne pouvez pas insérer de HTML dans la page JSF sans problème. Tous les HTML simples sont rendus avant l'arbre des composants JSF. Vous devez envelopper toute la vanille ordinaire dans des étiquettes <f:verbatim> pour qu'elles soient incluses dans l'arbre des composants JSF. Bien que cela soit conforme à la spécification, cela a fait l'objet de nombreuses 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 (May 2006)

il s'agit de la première sortie de la nouvelle équipe de développement JSF dirigée par Ryan Lubke. La nouvelle équipe a fait beaucoup de travail. Le cahier des charges a également été modifié. Le principal changement a été l'amélioration de la manipulation de la vue. Cela non seulement JSF complètement détaché de JSP, de sorte que l'on pourrait utiliser une technologie de vue différente de JSP, mais il a également permis aux développeurs d'inline simple HTML vanille dans le Page JSF sans tracas avec les étiquettes <f:verbatim> . Un autre objectif important de la nouvelle équipe était d'améliorer la performance. Pendant la durée de vie du Sun JSF Reference Implementation 1.2 (qui a été codé Mojarra depuis la construction 1.2_08, autour de 2008), pratiquement chaque construction a été livré avec des améliorations de performance (majeures) à côté des corrections de bug habituelles (mineures).

le seul inconvénient sérieux de JSF 1.x (y compris 1.2) est l'absence d'une portée de entre le demande et session portée, la soi-disant conversation portée. Cela a forcé les développeurs à s'embêter avec des éléments d'entrée cachés, des requêtes DB inutiles et / ou abuser de la portée de session chaque fois que l'on veut conserver les données du modèle initial dans la demande suivante afin de traiter avec succès des validations, des conversions, des modifications de modèle et des invocations d'action dans les applications Web plus complexes. La douleur peut être adouci par l'adoption d'une bibliothèque tierce partie qui conserve les données nécessaires dans la demande ultérieure comme MyFaces Tomahawk "1519220920 <t:saveState> composante, JBoss Couture conversation scope et MyFaces Orchestre cadre de conversation.

un autre inconvénient pour les puristes HTML/CSS est que JSF utilise le caractère : comme séparateur D'ID pour assurer l'unicité de l'élément HTML id dans la sortie HTML générée, surtout lorsqu'un composant est réutilisé plus d'une fois dans la vue (templating, iterating components, etc.). Comme il s'agit d'un caractère illégal dans les identificateurs CSS, vous devez utiliser le \ pour échapper au colon dans les sélecteurs CSS, ce qui donne des sélecteurs laids et bizarres comme #formId\:fieldId {} ou même #formIdA fieldId {} . Voir aussi comment utiliser l'ID D'élément HTML généré par JSF 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 des identifiants inutilisables, qui sont incompatibles avec la partie css des standards web .

Also, JSF 1.x n'a pas envoyé D'installations Ajax hors de la boîte. Pas vraiment un inconvénient technique, mais en raison du battage médiatique du Web 2.0 pendant cette période, il est devenu un inconvénient fonctionnel. Exadel a été précoce à introduire Ajax4jsf, qui a été soigneusement développé au cours des années et est devenu le partie centrale de la bibliothèque de composants JBoss RichFaces . Une autre bibliothèque de composants a été expédiée avec des puissances Ajax, la plus connue étant ICEfaces .

environ la moitié de la durée de vie du JSF 1.2, une nouvelle technologie de vue basée sur XML a été introduite: Facelets . Cela a offert d'énormes avantages au-dessus de JSP, surtout dans le domaine des Templiers.

JSF 2.0 (juin 2009))

il s'agit de la deuxième sortie majeure, avec Ajax comme mot à la mode. Il y a eu beaucoup de changements techniques et fonctionnels. JSP est remplacé par Facelets comme la technologie de vue par défaut et Facelets a été élargi avec des capacités pour créer des composants personnalisés en utilisant XML pur (le soi-disant composants composites ). Voir aussi Pourquoi Facelets est préféré au cours JSP comme le point de vue du langage de définition de JSF2.0 partir?

pouvoirs Ajax ont été introduits dans la saveur de la composante <f:ajax> qui a beaucoup de similitudes avec Ajax4jsf. Des Annotations et des améliorations de la Convention par rapport à la configuration ont été introduites dans le fichier kill the verbose faces-config.xml autant que possible. En outre, le caractère par défaut du séparateur d'ID de conteneur de nom : est devenu configurable, de sorte que les puristes HTML/CSS pouvaient respirer soulagé. Tout ce que vous devez faire est de le définir comme init-param dans web.xml avec le nom javax.faces.SEPARATOR_CHAR et s'assurer que vous n'utilisez pas le caractère vous-même n'importe où dans les ID du client, tels que - .

enfin et surtout, une nouvelle portée a été introduite, la view scope. Il a éliminé un autre important JSF 1.x désavantage décrit ci-dessus. Vous venez de déclarer le bean @ViewScoped pour activer la portée de la conversation sans tracasser toutes les façons de conserver les données dans les demandes ultérieures (conversationnel). Un @ViewScoped bean vivra aussi longtemps que vous soumettez par la suite et naviguez vers la même vue (indépendamment de l'onglet/fenêtre de navigateur ouvert!), soit de façon synchrone ou asynchrone (Ajax). Voir aussi différence entre la portée de la vue et de la demande dans les haricots gérés et Comment choisir la bonne portée de haricots?

bien que pratiquement tous les inconvénients de JSF 1.x ont été éliminés, il ya JSF 2.0 bugs spécifiques qui pourrait devenir un obstacle de taille. Le @ViewScoped échoue dans les manipulateurs d'étiquettes en raison d'une émission d'œufs de poulet en épargne partielle de l'état. Ceci est fixé dans la JSF 2.2 et rétroporté dans Mojarra 2.1.18. Aussi passant attributs personnalisés comme le HTML5 data-xxx n'est pas supporté. Ceci est corrigé dans JSF 2.2 par la nouvelle fonctionnalité passthrough elements/attributes. En outre, la mise en œuvre JSF Mojarra a son propre ensemble de questions . Relativement à une beaucoup d'entre eux sont liés au comportement parfois unintuitif de <ui:repeat> , le New partial state saving implementation et le poorly implemented flash scope . La plupart d'entre eux sont fixés dans un Mojarra 2.2.x version.

autour du JSF 2.0 time, PrimeFaces a été introduit, basé sur jQuery et jQuery UI. Elle est devenue la bibliothèque de composants JSF la plus populaire.

JSF 2.2 (May 2013)

avec L'introduction du JSF 2.2, HTML5 a été utilisé comme mot à la mode, bien que cela ait été techniquement juste pris en charge dans toutes les versions plus anciennes du JSF. Voir aussi JavaServer Faces 2.2 et support HTML5, pourquoi XHTML est 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, comme bouton radio tableless personnalisé les groupes .

mis à part les bugs spécifiques à la mise en œuvre et certaines "petites choses ennuyeuses" telles que l'incapacité d'injecter une 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.

à base de Composants MVC vs Demande de MVC

certains peuvent choisir que le principal inconvénient de JSF est qu'il permet très peu de contrôle à grain fin sur le généré HTML/CSS / JS. Ce n'est pas le propre de JSF, c'est juste parce que c'est un composante basée MVC framework, pas un demande (action) basée MVC framework. Si un haut degré de contrôle du HTML/CSS/JS est votre exigence principale lors de l'examen d'un cadre MVC, alors vous ne devriez pas déjà être en train de regarder un cadre MVC basé sur un composant, mais un cadre MVC basé sur une demande comme MVC de printemps . Vous avez seulement besoin de prendre en compte que vous aurez à écrire tout ce boilerplate HTML/CSS/JS vous-même. Voir aussi différence entre MVC Request et MVC Component .

Voir aussi:

453
répondu BalusC 2017-05-23 15:02:47
la source

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

Deux grands JSF inconvénients:

  1. grande courbe d'apprentissage. Le JSF est complexe, c'est juste vrai.
  2. Son composant de la nature. Cadre basé sur les composants tente de cacher la vraie nature du Web, qui vient avec une quantité énorme de complications et de catastrophes (comme ne pas soutenir obtenir dans JSF au sein de presque 5 ans).

    IMHO cacher la requête/réponse HTTP du développeur est une énorme erreur. D'après mon expérience, chaque structure basée sur des composants ajoute de l'abstraction au développement Web, et que l'abstraction entraîne des frais généraux inutiles et une complexité accrue.

Et mineur inconvénients qui viennent à mon esprit:

  1. par défaut ID de l'objet est composé de son les pièces d'identité des parents, par exemple le formulaire1:button1.
  2. Pas de moyen facile de commentaire-out de page incorrecte du fragment. Tag <ui:remove> nécessite un contenu syntaxiquement correct qui est analysé de toute façon.
  3. composants tiers de faible qualité qui, par exemple, ne vérifient pas isRendered() dans la méthode processXxx() avant de continuer.
  4. Incorporant MOINS & Sencha est dur.
  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 doivent être réécrits.

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

regardez 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, prenez un coup d'oeil à la réussite de Rails, Grain, Django, Jouer! Cadre-ils sont tous basés sur l'action et ne pas essayer de se cacher du programmeur vraie demande/réponse et nature apatride du web.

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

Hope il aide quelqu'un à faire ses choix en ce qui concerne le front-end.

49
répondu G. Demecki 2014-01-25 23:31:01
la source

quelques inconvénients qui apparaissent à l'esprit:

  1. JSF est une composante de base de cadre. Cela comporte des restrictions inhérentes qui: ont à voir avec l'obéissance à la composant de modèle.
  2. AFAIK JSF supporte seulement le POST, donc si vous voulez un GET somewhere vous avez pour faire un simple servlet/JSP.
  3. la plupart des composants essaient de fournir des abstractions sur des domaines comme bases de données relationnelles et front-end JavaScript, et beaucoup de fois ces abstraction sont "fuyantes" et très difficiles à débuguer.
  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 elles sont très difficiles à optimiser en termes de performances, car il y a plusieurs couches 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 qui sont habituellement utilisés avec JSF n'ont rien à voir avec le fonctionnement de web desigers. Les éditeurs WYSIWYG pour JSF sont primitifs et dans tous les cas, votre concepteur vous donnera HTML/CSS que vous devrez passer des âges à convertir.
  6. des choses comme les expressions EL ne sont pas vérifiées statiquement et le compilateur et IDEs ne font pas un bon travail pour trouver des erreurs, donc vous finirez avec des erreurs que vous devrez attraper à l'exécution. Cela pourrait être bien pour le langage dynamiquement dactylographié comme Ruby ou PHP, mais si je dois résister à la simple bloat de L'écosystème Java, je demande Dactylographie pour mes gabarits.

pour résumer: le temps que vous économiserez avec JSF, d'éviter d'écrire le code JSP/servlet/bean boilerplate, vous le passerez à x10 pour le mettre à l'échelle et faire exactement ce que vous voulez qu'il fasse.

22
répondu Kay Pale 2011-01-12 22:35:36
la source

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

  • HTML dans les différentes incarnations. Ne prétends pas que tu n'as 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 avez besoin de savoir cela.
  • CSS -- que ça vous plaise ou non. Il n'est pas si mal, en réalité, il existe quelques outils sympathiques au moins.
  • XML -- JSF sera probablement le premier endroit où vous utiliserez des espaces de noms à ce degré.
  • Servlet Specification. Tôt ou tard, vous entrerez dans les méthodes d'appel dans ce paquet. À part ça, tu dois savoir comment tes Facelets se transforment en XHTML ou autre.
  • JSP (surtout si vous savez pourquoi vous n'en avez pas besoin dans JSF)
  • JSTL (encore une fois, surtout pour faire face au cadre d'héritage)
  • Expression Language (EL) dans ses diverses formes.
  • ECMAScript, JavaScript, ou n'importe quel autre nom que vous voulez lui donner.
  • 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 de vous cacher cela, mais vous avez encore besoin pour savoir ce qui se passe.
  • the DOM. Et comment un navigateur utilise. Voir ECMAScript.
  • Événements DOM -- un sujet à lui tout seul.
  • Java Persistance de l'Architecture (JPA), c'est si vous voulez que votre application à toute extrémité arrière de la base de données.
  • Java lui-même.
  • JSEE tant que vous y êtes.
  • Le Contexte de l'Injection de Dépendances spécification (CDI) et comment il affrontements avec et est utilisé avec JSF 2.0
  • JQuery -- j'aimerais que vous vous en passiez.

maintenant, une fois que vous avez fait avec ce que vous pouvez obtenir avec les spécifications propriétaires, à savoir les bibliothèques de composants et les bibliothèques de fournisseurs, vous ramasserez le long du chemin:

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

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

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

donc ... ça rend les choses faciles? Bien sûr, JSF 2.0 est "facile" tant que tout ce que vous voulez faire est les pages web les plus basiques avec les interactions les plus simples.

simplement dit, JSF 2.0 est le plus compliqué et encombrant méli-mélo de technologies collées comme il existe dans l'univers du logiciel aujourd'hui. Et je ne peux pas penser à quoi que ce soit que je préférerais utiliser.

17
répondu AlanObject 2011-09-19 06:10:05
la source
  1. développeurs inexpérimentés généralement vont créer des applications qui sont douloureusement lents et le code sera vraiment laid 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 passer plus de temps à lire les messages balusc sur internet que de travailler réellement:) après un certain temps, il sera de moins en moins de ce, mais ça peut toujours être ennuyeux.
  3. encore plus ennuyeux quand vous découvrez que le problème n'est pas dû à votre manque de connaissances/erreur mais plutôt à un bug. Mojarra était (est?) assez buggé, et une autre couche de composants ajoute encore plus de problèmes. Richfaces était le plus gros morceau de logiciel merdique jamais écrit :) Je ne sais pas comment il est maintenant sur la version 4. Nous avons des Primefaces, ce qui est mieux, mais vous rencontrerez quand même des bugs ou un manque de fonctionnalités, surtout avec des composants plus exotiques. Et maintenant vous devrez payer pour les mises à jour de Primefaces. Donc je dirais que son buggy mais il s'améliore surtout après la version 2.2 a corrigé quelques problèmes avec spec. Cadre de plus en plus mature, mais encore loin d'être parfait (peut-être myfaces mieux?).
  4. Je ne le trouve pas particulièrement flexible. Souvent, si vous avez besoin de quelque chose de très personnalisé et il n'y a pas de composants qui le fait - il sera un peu douloureux. Encore une fois, je parle du point de vue du développeur moyen - celui avec des délais, tutoriels de lecture rapide, et la recherche stackoverflow lorsque se coincer 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 à faire quelque chose que vous voulez :) besoin d'être prudent dans l'évaluation si son meilleur pour créer votre propre ou torture composante existante. En fait, si vous créez quelque chose de vraiment unique, Je ne recommande pas JSF.

dans bref, mes inconvénients seraient: la complexité, les progrès de développement pas très doux, 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, c'est mon expérience avec le cadre d'autres pourraient avoir des opinions différentes, donc la meilleure façon est de l'essayer pendant un certain temps pour voir si c'est pour vous (juste quelque chose de plus complexe - pas des exemples naïfs - JSF brille vraiment là:) cas de la meilleure utilisation IMHO pour JSF est les applications d'affaires, comme CRMs, etc...

12
répondu Koks Skirtumas 2014-06-14 17:27:16
la source

" JSF va sortir la couche de vue HTML et JavaScript 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 votre propre qui vous avez le contrôle total sur ce qui est rendu. Il ne s'agit que d'un xhtml dont vous avez besoin pour créer vos composants personnalisés avec JSF 2.0.

11
répondu Cagatay Civici 2010-09-06 17:35:17
la source

nous avons développé un projet type avec JSF (c'était une recherche de trois semaines donc nous avons peut-être perdu des choses!)

nous essayons d'utiliser le jsf de base, si un composant est nécessaire, nous avons utilisé des 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 usecases:

  1. une page avec une grille. La grille est chargée via ajax et devrait soutenir le tri et la pagination
  2. une page de magicien 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 service) doit être affichée sur la même page de l'assistant sans naviguer à la page suivante.

nous avons trouvé que:

  1. vous devez utiliser quelques hacks de omniFaces pour faire la vue JSF l'état fixe. L'état JSF sera corrompu lorsque vous incluez des pages via ajax les unes dans les autres. Cela semble être un bug dans JSF et peut être corrigé sur les prochaines versions (pas dans 2.3).
  2. le flux JSF ne fonctionne pas correctement avec ajax (ou nous ne pourrions pas le faire fonctionner! Nous essayons d'utiliser primeface wizard component à la place, mais la validation du client ne semble pas supportée et moyenne alors qu'elle n'était pas standard JSF flow.
  3. lors de l'utilisation de certains composants jQuery comme jqGird, et vous devez charger les résultats JSON, alors il vous est conseillé d'utiliser pur servlet, le JSF ne fera rien pour vous. Donc, si vous utilisez ce genre de composants, votre conception ne conviendra pas au JSF.
  4. nous essayons de faire quelques scripts client lorsque ajax complète par ajaxComplete et nous avons constaté que le PF 4 a mis en œuvre ses propres événements ajax. Nous avions quelques composants jQuery et nous avons besoin de changer leur code.

si vous changez l'échantillon ci-dessus en un Non Ajax projet (ou au moins moins moins projet ajax) vous ne ferez pas face à beaucoup de questions ci-dessus.

nous résumons notre recherche comme:

JSF ne fonctionne pas bien sur un site internet entièrement ajax.

bien sûr, nous trouvons beaucoup de belles fonctionnalités dans JSF qui peuvent être très utiles dans certains projets, alors considérez vos besoins de projet.

prière de se reporter aux documents techniques de JSF pour examiner les avantages du JSF, et à mon avis le plus grand avantage du JSF, est le soutien complet et énorme de @BalusC ; -)

8
répondu Alireza Fattahi 2014-04-30 16:32:17
la source

Je ne suis pas un expert des visages de serveur Java du tout. Mais IMHO le principal inconvénient est qu'il est Côté Serveur. Je suis fatigué d'apprendre et d'utiliser les cadres de la couche de présentation Web côté serveur comme ASP.NET formulaires Web, ASP.NET MVC, Java Server Faces, Struts, PHP frameworks et ruby on rails frameworks. J'ai dit au revoir à tous, et j'ai dit bonjour à Angularjs et Tapuscrit. Ma couche de présentation s'exécute sur le navigateur. Je n'a pas d'importance si elle est desservie par Windows IIS s'exécute php ou ASP.NET ou si il est servi par un serveur web Apache sous Linux. J'ai juste besoin de savoir un cadre qui fonctionne partout.

juste mes deux cents.

8
répondu Jesús López 2015-03-17 15:57:54
la source

pour moi, le plus grand défaut du JSF est un support médiocre pour les pages générées de manière programmatique (dynamique).

Si vous voulez construire votre page (Créer le modèle de composant de 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 n'est généralement pas disponible. Il y a beaucoup de points où vous devez expérimenter et le développement est calme lent. Beaucoup de choses ne fonctionnent pas comme vous le feriez attendre. Mais en général, il est possible de le pirater d'une façon ou d'une autre.

La bonne chose est que ce n'est pas un problème dans la philosophie ou l'architecture du JSF. Il est tout simplement pas assez élaboré (autant que je sache).

JSF 2 a apporté des composants composites qui devraient faciliter le développement des composants, mais leur soutien à la construction dynamique (programmatique) est très faible. Si vous surmontez calme complexe et presque sans documentation processus de la construction de composants en Composite dynamique, vous découvrirez que si vous nichez quelques composants composites un peu plus profondément, ils arrêtent de fonctionner, en jetant quelques exceptions.

mais il semble que la communauté JSF soit consciente de ces lacunes. Ils travaillent là-dessus comme vous pouvez le voir avec 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.

5
répondu Ondrej Bozek 2015-12-31 00:31:48
la source

commentant mes derniers mois D'expérience Primefaces/JSF:

  • si vous pouvez utiliser des composants" disponibles sur le marché", je suppose que ce n'est pas terrible.
  • cependant, il ne joue pas bien dès que vous sortez et avez besoin d'UIs personnalisé. - Par exemple, nous avions besoin D'utiliser bootstrap de Twitter pour notre projet. (Non primefaces bootstrap).
    • maintenant nos pages fonctionnent comme suit:
      • chargement de la Page.
      • L'utilisateur interagit avec un Primefaces qui a la fonctionnalité ajax
      • de Bootstrap, javascript liaisons pause
      • nous exécutons javascript supplémentaire pour tout changer

la promesse de JSF d'éviter d'écrire javascript s'est transformée en écriture javascript plus que nous ne l'aurions fait si nous n'avions pas utilisé Primefaces--et que javascript est de corriger ce Primefaces briser.

c'est un évier temporel ... à moins que vous n'utilisiez à nouveau des trucs" de série". Aussi vraiment laid (Primefaces) quand on doit travailler avec le sélénium. Il peut être fait, mais là encore, il y a seulement tellement de temps.

certainement éviter cela si vous travaillez avec une équipe UX / design et besoin de itérer rapidement sur L'UI--vous pouvez gagner du temps en apprenant jquery/écriture HTML droite--ou en regardant react/angular.

5
répondu rprasad 2016-08-10 18:28:14
la source

JSF a beaucoup d'avantages, la question étant sur le désavantage permettez-moi d'ajouter quelques points sur elle.

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

  • avez-vous assez de membres seniors dans votre équipe qui peuvent suggérer le meilleur des commandes adaptées à chaque scénario?
  • avez-vous de la bande passante pour accueillir la première la courbe d'apprentissage?

  • avez-vous assez de l'expertise de votre équipe qui peut examiner le cadre du programme

    trucs produit par les développeurs?

si votre réponse est " non " aux questions, vous pouvez vous retrouver dans une base de données non maintenable.

1
répondu Sam 2014-10-14 12:33:10
la source

JSF a seulement un inconvénient: avant de commencer le développement "JSF", vous devez clairement comprendre le développement web, java de base et l'architecture front-end.

de nos jours "nouveaux" cadres JavaScript essayez juste de copier/coller " JSF " modèle basé sur les composants.

0
répondu Armen Arzumanyan 2018-04-28 22:37:34
la source

parmi tous les cadres" grand public " tels que MVC à ressort, Wicket, Tapestry, etc., le JSF de Java EE avec ses composants composites est la couche de présentation la plus élaborée et la technologie axée sur les composants fournis. Il est un peu lourd et incomplet par rapport aux solutions fournies par HybridJava.

0
répondu Dima 2018-04-29 18:46:38
la source

Autres questions sur asp.net-mvc jsf jsf-2