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

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?

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:

• Différence entre Request MVC et Component MVC
• Différence entre JSP, Servlet et JSF
• Quels sont les principaux inconvénients de JSF 2.0?
• Est-il possible d'utiliser JSF + Facelets avec HTML 4/5?
• Quand utiliser <ui: include>, des fichiers de balises, des composants composites et / ou des composants personnalisés?

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.

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

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.

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.

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.

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.

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.