Quel est le besoin de JSF, lorsque l'interface utilisateur peut être réalisée avec des bibliothèques JavaScript telles que jQuery et AngularJS


116

Je lisais à propos de JSF qu'il s'agissait d'un cadre d'interface utilisateur et qu'il fournissait des composants d'interface utilisateur. Mais en quoi est-il meilleur ou différent du nombre de composants disponibles à partir de jQueryUI, AngularJS, ExtJS ou même de HTML, CSS et JavaScript.

Pourquoi quelqu'un devrait-il apprendre JSF?


3
avantages du html généré par le serveur: recherche des moteurs de recherche, masquage des vues en fonction de l'autorisation. sinon, nous l'avons abandonné pour pur ajax ui.
Neil McGuigan

5
J'ai également abandonné JSF au profit du backend AngularJS + RESTful. (Pommes et oranges, mais Angular est tellement agréable que je n'ai pas besoin de beaucoup des avantages de JSF)
arg20

JSF est un framework MVC basé sur des composants qui repose sur l'API Servlet et fournit des composants via des taglibs qui peuvent être utilisés dans JSP ou toute autre technologie de vue basée sur Java telle que Facelets.
Divyesh Kanzariya

Réponses:


154

JSF en JSP / Servlet / HTML / CSS / JS est comme jQuery en JS: faites plus avec moins de code. Pour prendre PrimeFaces ( basé sur jQuery + jQuery UI) comme exemple, parcourez sa vitrine pour voir des exemples de code complets. BootsFaces ( basé sur jQuery + Bootstrap UI) a également une vitrine avec des exemples de code complets. Si vous étudiez attentivement ces exemples, vous verrez que vous avez essentiellement besoin d'une simple classe Javabean comme modèle et d'un fichier XHTML comme vue.

Notez que vous ne devriez pas voir JSF comme un remplacement de HTML / CSS / JS seul, vous devez également prendre en compte la partie côté serveur (en particulier: JSP / Servlet). JSF supprime le besoin de toutes les règles standard de collecte des paramètres de requête HTTP, de conversion / validation, de mise à jour des valeurs du modèle, d'exécution de la bonne méthode Java pour faire les affaires et de génération du code standard HTML / CSS / JS. Avec JSF, vous vous retrouvez essentiellement avec une page XHTML comme définition de vue et une classe Javabean comme définition de modèle. Cela accélère considérablement le développement.

Comme pour tout framework Web MVC basé sur des composants, vous avez dans JSF un contrôle moins fin sur le HTML / CSS / JS rendu. L'ajout de code JS personnalisé n'est pas si simple car vous devez également prendre en compte l'état de la vue JSF côté serveur (par exemple, l'activation d'un bouton désactivé côté JS n'activera pas le bouton côté JSF, qui est à son tour un énorme avantage de sécurité). Si c'est cependant un showstopper majeur, recherchez plutôt un framework Web MVC basé sur l'action comme Spring MVC . Vous ne prendre en compte que vous devez écrire tout ce code HTML / CSS / JS (et la prévention contre les attaques XSS, CSRF et DOM-manipulation!) Vous - même . De plus, si vous passez de Facelets à JSP, vous manquerez également des fonctionnalités avancées de création de modèles.

D'autre part, si vous avez un grand site Web basé sur JSP / Servlet / HTML / CSS / JS / jQuery et que vous souhaitez refactoriser le code réutilisable JSP / Servlet / HTML / CSS / JS / jQuery répété en composants réutilisables, alors une des solutions serait JSF. Des modèles personnalisés, des fichiers d'étiquettes et des composants peuvent y contribuer. Dans cette perspective, JSF se situe au-dessus de JSP / Servlet / HTML / CSS / JS / jQuery (et c'est aussi pourquoi il est assez important de comprendre ces bases avant de plonger dans JSF).

Vous pouvez trouver un projet basé sur JSF de lancement dans le monde réel ici: Java EE Kickoff App . Vous verrez qu'il contient à côté de JSF de bons HTML5 , CSS3 et jQuery .

Voir également:


15
Faire plus avec moins de code? Mais avec plus de xml ... quel compromis ... en plus, cela vous donne de la flexibilité
Danubian Sailor

33
Dans JSF 2.0+, xml n'est pas nécessaire.
Cagatay Civici

5
Nous avons des annotations dans JSF 2.0
VdeX

1
Il semble qu'il n'y ait pas de délimitation claire entre la couche métier / contrôleur et la vue, avec JSF, car une grande partie de la vue est générée sur le serveur. Je comprends que tout est compilé sur le serveur avant d'être envoyé au navigateur, mais je préfère que mon objet Java renvoie des données que la vue rend, plutôt que d'envoyer une logique / des données de rendu.
Rick

1
d'accord JSF est une chose côté serveur avec un contrôle puissant sur HTML.
Plain_Dude_Sleeping_Alone

28

JSF a été créé pour faire en sorte que les boutiques Java n'aient pas à apprendre des choses comme jQuery et à créer un JS complexe, mais se concentrent plutôt sur une pile purement Java. Dans un monde où le temps, c'est de l'argent et de nombreux endroits se concentrant déjà sur le développement Java, un langage / élément de moins dans la pile rend la formation et la maintenance plus rapides et donc moins chères.

J'ajouterai que JavaScript est facile à devenir un cauchemar de maintenance sur de grandes équipes, surtout si certains des développeurs du projet ne sont pas très avertis du Web.


Donc, si je suis assez à l'aise avec JQuery JS, etc. Je n'ai pas besoin de me concentrer sur JSF?
sushil bharwani du

2
Tout dépend du problème que vous essayez de résoudre et de l'équipe avec laquelle vous le résolvez.
Andrew White

1
Je suis d'accord sur l'équipe, mais je suis intéressé à apprendre quels sont les différents problèmes que JSF peut résoudre et js jQuery, etc. J'essaie juste de développer la motivation pour apprendre JSF
sushil bharwani

1
Aucun, cela fournit simplement une manière différente de résoudre les mêmes problèmes.
Andrew White

8
Même si vous êtes vraiment à l'aise avec JQuery, JSF est toujours très utile. Il fournit un moyen simple de connecter le code côté serveur aux représentations côté client. Certains «composants composites» de Facelets ne sont qu'un wrapper assez fin autour de HTML et JS (y compris JQuery). Ils sont un jeu d'enfant à construire et, en général, facilitent simplement l'ensemble de la connexion côté client-serveur.
Arjan Tijms

23

Avec Javascript et des frameworks tels que jQuery, vous avez une flexibilité totale et un contrôle total. Avec les extensions, vous perdez beaucoup de contrôle et devez vous adapter au framework. Avec JSF, vous perdez totalement le contrôle et devez totalement vous adapter au framework. Vous êtes appelé dans les cycles de vie, etc. et finalement vous n'avez aucun contrôle sur le moment où l'appel au serveur peut être effectué et où pas. Si vous devez faire quelque chose de «spécial», vous êtes dans une position très difficile. Et dans le monde JSF, même les éléments de base tels que le tri de table multicolonne ou les champs dans lesquels vous ne pouvez taper qu'un jeu limité de caractères (comme un champ numérique) sont considérés comme «spéciaux».

Cependant, plus vous avez de flexibilité, plus vous pouvez commettre d'erreurs ou de mauvaises pratiques. Une grande flexibilité ne fonctionne qu'avec des programmeurs très intelligents, d'autres transformeront le projet en cauchemar ingérable.

Mais, avec JSF et sa flexibilité limitée, il n'y a toujours que quelques (ou même une seule) façon correcte de faire quelque chose. Vous êtes très limité, vous ne pouvez pas créer de raccourcis, vous devez écrire plus de XML, etc. - mais lors de l'adaptation au standard, il y a un meilleur contrôle sur le code que les programmeurs inexpérimentés ou peu qualifiés produiront. En conséquence, les grandes entreprises aiment JSF parce qu'il est «plus sûr» pour elles.

Quand je suis passé de GWT à JSF, j'ai été choqué, combien de choses, c'était naturel pour moi, étaient considérées comme très atypiques et combien de choses simples étaient si difficiles à réaliser. De plus, même apporter les plus petits changements, tels que l'ajout d'un signe ':' après l'étiquette, qui dans l'application alimentée par GWT / jQuery changerait une fonction générant l'étiquette, nécessitait de changer des dizaines de fichiers avec des propriétés localisées, ce qui n'était même pas pris en compte par n'importe qui sauf moi étrange ...


7
PrimeFaces est basé sur jQuery afin que vous ayez beaucoup de flexibilité côté client.Les composants PrimeFaces fournissent également de nombreux hooks côté client et serveur en tant que rappels d'événements à personnaliser. Les API Javascript peuvent être remplacées et CSS également pour une apparence personnalisée. : label peut être configuré globalement dans web.xml pour un caractère plus convivial pour jQuery.
Cagatay Civici

1
D'accord. La règle générale est la suivante: ne pas utiliser de framework nécessite une programmation javascript avancée et sera difficile à maintenir mais permet une puissance et une complexité nettement plus grandes, tandis que le recours aux frameworks sera plus facile à créer et à maintenir, mais limitera la capacité potentielle de l'application.
KTys

10

Les avantages de l'utilisation de JSF ne se limitent pas à la génération de xhtml + css + js. Parfois, JSF impose une restriction sur le balisage que vous pouvez générer, comme tout framework basé sur des composants. Mais JSF n'est pas seulement pour cela, son cycle de vie aide énormément. Après avoir validé l'entrée, il peut mettre à jour le modèle et synchroniser vos beans côté serveur sans aucun effort. vous dites simplement "quel que soit le type d'utilisateur ici, vérifiez si c'est un nombre, si oui, stockez-le dans la propriété YY dans l'objet XX" et JSF fera tout cela.

Alors oui, vous pouvez toujours utiliser JQuery, JS, etc. Mais JSF offre de nombreux avantages quand il s'agit d'écrire du code côté serveur et vous évite beaucoup de choses.


9

Je ne suis pas du tout d'accord que jsf ajoute quoi que ce soit. Cela ne fait qu'ajouter des frais généraux. Faire des trucs d'interface utilisateur sur le serveur est la chose la plus ridicule que j'aie jamais entendue. Et javascript sur les grandes équipes fonctionne très bien - c'est ce qu'on appelle le code de réutilisation.

Enveloppez simplement le jquery dans des balises jsp, c'est tout ce dont vous avez besoin et vous avez terminé, et ne supportez pas les problèmes de.shackles et d'évolutivité avec.jsf et richfaces.


14
JSF est orienté vers les applications basées sur des formulaires. jQuery est sympa (diable, beaucoup de bibliothèques de composants JSF populaires comme PrimeFaces, RichFaces et IceFaces l'utilisent même sous les couvertures), mais jQuery ne simplifie en aucun cas le traitement des formulaires soumis du côté serveur. L'utilisation de JSP / Servlet simples ne résultera qu'en un code passe-partout terrible. Encore une fois, JSF n'est pas seulement HTML / CSS / JS, mais aussi JSP / Servlet.
BalusC

2
Je pense que si vous en lisez plus sur JSF en général et sur le cycle de vie d'une page JSF en particulier, vous pourriez changer d'avis. Là encore, vous pourriez ne pas le faire.
Ahmed Anwar

5

Ayant travaillé avec JSF, Spring MVC, Struts, Grails, JQuery et ExtJS, mon opinion est que Grails + ExtJS est une combinaison puissante.

Je choisirais Grails plutôt que JSF n'importe quel jour. J'aime l'exhaustivité d'ExtJS en tant que framework et bibliothèque côté client, mais il est livré avec une courbe d'apprentissage plus raide que JQuery.


3

Voici les plus grandes différences entre jQuery et JSF:

  • pas d'architecture MVC
  • pas de contrôle d'état (stocker la date dans la session ou la conversation, nettoyage automatique, etc.)
  • pas de bibliothèque de validation (par défaut)
  • pas de bibliothèque de modèles
  • pas de navigation / routage avancé
  • côté client

jQuery n'a jamais été conçu pour être utilisé comme un cadre Web complet. Il était plus destiné à remplacer le code JS de bas niveau afin que l'écriture de JS devienne plus facile et plus puissante en moins de lignes de code.

Et il devrait donc surtout être utilisé pour ajouter du comportement sur des éléments HTML.


2

Ayant utilisé le framework ExtJS pour une grande application Web, je sais à quel point il est facile à utiliser. ExtJS (Schena) est le mieux adapté pour les interactions de base de données (Oracle 11g) dans l'architecture MVC. La vue était pour les interactions visuelles / utilisateur. Le contrôleur a spécifié le «traitement» et les déclencheurs qui devaient être utilisés pour les packages PLSQL (l'API pour le CRUD, les requêtes de sélection SQL, etc.). Le modèle et les fichiers de stockage ont été utilisés pour «mapper» les éléments de données vers le visualiseur / les entrées.

ExtJS ne convient pas aux interfaces Web non gourmandes en bases de données - où Angular JS peut être un meilleur ajustement.

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.