mars
2008
Un article de djo.mos
Bonjour,
Après avoir travaillé sur 3 applications JSF (faisant partie du même projet) ces 5 derniers mois, et maintenant que c’est fini (enfin, presque …), j’aimerais parler du the good, the bad and the ugly, bref, une sorte de retour d’expérience sur l’utilisation de JSF.
Je vais commencer par the good.
- Les managed beans: là, c’est le bonheur. Du java pur et dur, on est libre de s’exprimer comme on veut (héritage/composition/délégation, etc.). Ajoutez Spring dans l’equation et on est proches de l’orgasme cérébral !
Enfin, avec quelques limitations bien sûr (signature des actions, etc.). - Richfaces/Ajax4jsf: J’en ai parlé à maintes reprises dans le forum, mais je tiens à en reparler ici: Impossible AMHA de battre Ajax4jsf comme moyen de faire de l’ajax via une taglib. J’ai bien dit pour une taglib car j’ai vu comment on procède avec Wicket, et c’est beaucoup plus puissant, mais c’est normal car on passe par Java.
- L’approche composants: je ne suis pas spécialement doué en HTML/CSS, et n’o n’avait pas une personne pareille dans l’équipe. C’est pour cela que j’ai énormément apprécié le fait qu’avec quelques lignes XML pour décrire le composant dans la page JSF, j’obtiens à l’exécution des trucs à couper le souffle côté visuel (Merci Richfaces)
Trois points seulement … mais c’est déjà ça 
Mais je pense que vous êtes nombreux à attendre l’autre partie plutôt, the bad and the ugly 
- Tooling: là, c’est un véritable cauchemar. On est sous eclipse europa, qui offre quelques fonctionnalités d’un IDE JSF, mais il en est encore loin … très loin. En fait, ça a tourné au vinaigre dès qu’on ne fait plus du JSF de base (sans jeux de composants additionnels ni facelets ni Spring).
Mais dès qu’on essaies de faire quelque chose de puissant, eclipse nous a complètement laché.
Il perd complètement les boules avec facelets, ce qui est tout simplement choquant, vu qu’aucun développeur JSF sérieux n’oserait faire sans facelets.
D’ailleurs, eclipse s’est amélioré au fils des versions de maintenance (3.3.1.1 et 3.3.2), dans le sens où il accepte par exemple les pages xhtml dans l’editeur des règles de navigation, chose qu’il refusait avant, où qu’il offre l’auto-completion sur les jeux de composants standards (core et html) dans une page xhtml, mais il refuse de fonctionner pour facelets et tout autre jeu de composants.
Exit l’aspect IDE et nous revoilà à l’époque de notepad, où on est censé taper des pages de quelques dizaines de lignes d’XML sans se tromper dans le nom d’un composant où d’un attribut.De plus, mais là c’est vivable, si on fait gérer ses managed beans par Spring, eclipse ne peut plus faire de l’auto-completion sur les ELs. D’ailleurs, il ne le fait plus du moment qu’on est dans une page xhtml et non pas JSP.
- Ca figure dans la liste des bonnes chose, mais également ici: le fait qu’on bosse sur les composants et que ça génère du HTML. J’en ai vu des vertes et des pas mûres à cause de cela, et le pire que tu ne peux rien y faire: des liens qui ne marchent pas, générant des erreurs JavaScript, des inputs qui ne sont pas envoyés lors d’un submit, des composant qui violent leur contrat, notamment les valueChangeListeners sur les inputText, etc.
On se retrouvait alors obligés à faire de l’acrobatie en essayant de contourner ces problèmes avec des solutions plus sordides l’une que l’autre. - Je sais que ça devrait être résolu dans JSF 2.0, ou encore déjà avec Seam et RestFaces, mais l’aspect fortement stateful de JSF peut vraiment devenir ennuyant, surtout si l’application est destinés à un utilisateur non forcément informaticien. Vas lui expliquer qu’il vaut mieux éviter le bouton retour du navigateur ou les F5 ou encore qu’il doit suivre une séquence particulière dans les pages pour arriver au résultat, et qu’il ne peut pas bookmarker des pages, etc.
- Les maudits erreurs de « View has Expired », et la gestion des erreurs en général qui est, et c’est un doux euphémisme, exécrable.
- Facelets: je l’ai déjà dit à maintes occasions: JSF sans Facelets c’est comme les oeufs avant la maîtrise du feu, mais la gestion/rapport d’erreurs de facelets est parfois cryptique et n’aide aucunement à leur localisation/correction.
Par exemle, si dans un include on se trompe du nom du fichier à inclure, on obtient un beau 404 quand on essaie d’accèder à la page mère au lieu d’un message indiquant clairement l’origine de l’erreur… ainsi que dans d’autre cas où on obtenait des messages d’erreur cryptés sur 128 bits sans même le numéro de la ligne en cause. - Difficile de faire quoi que soit d’utile avec le scope request. On se retrouve obligé de passer au scope session.
- Bouffeur de CPU: J’en parle dans ce billet.
- Mais le point noir à mon avis est la difficulté sordide de la tache de développement de composants personnels … C’est vrai que facelets essaies de simplifier ça, mais ça permet pas de développer de véritables composants personnels.
Impressionnant cette liste, non ? En relisant ce billet, je sens que c’est injuste pour JSF, car on a tout de même fait pas mal de trucs puissants avec, et ce en un temps record, ce qui est ne serait pas forcément la conclusion tirée par quelqu’un lisant ce billet 
Pour résumer et rectifier un peu le tir, je dirais qu’avec JSF, on est pas loin de la règle de 80/20, mais que je transformerais en 80/60 au risque de casser sa beauté
- On fait 80% du boulot en 60% du temps attribué
- Et on se retrouve à combattre les 20% restantes du boulant dans le 40% du temps restant
Enfin, pour conclure, je ne suis aucunement en train de lancer une croisade contre JSF, loin de là même: JSF est toujours une option valable à envisager pour un nouveau projet. Seulement, comme tuotes les autres technos, JSF a ses défauts et un prix à payer.
Bonjour,
je suis un utilisateur quotidien de JSF. Je ne suis pas tout à fait d’accord avec le billet ci-dessus. Je m’explique : JSF ne peut-être juger dans le cadre d’une prestation ponctuelle et commandée. JSF est conçu pour une utilisation à long terme. J’entends par là la conception d’un Framework d’entreprise avec des composants réutilisables spécifiques.
RichFaces, c’est beau, c’est bien. Mais ça ne répond pas forcément aux nécessités des projets informatiques (ou en tout cas pas en totalité).
Aussi, il peut-être intéressant de perdre du temps sur un projet en développant ses propres composants et pouvoir les réutiliser plus tard sur des projets similaires. J’avouerai quand même que l’aspect composant, même si c’est génial niveau réutilisabilité (comme dit avant), cela comporte également de nombreux défauts et désagréments (lisibilité du code, beaucoup plus aisée quand on pense au niveau de l’action… bugs récurrents et semi-aléatoires de JSF etc.).
Je pense qu’on ne peut pas juger pleinement JSF si l’on utilise essentiellement des librairies externes. Il faut développer ses propres librairies pour pouvoir réellement toucher au coeur du Framework, j’entends par là le cycle de vie de la requête. Un Framework doit, selon moi, être essentiellement jugé par rapport à son cycle de vie. En ce sens, je préfère Struts2 à JSF (l’aspect très simple et totalement paramétrable de la stack d’appel du cycle de vie de Struts2 est un vrai bonheur), mais JSF reste un Framework hautement productif dans le cadre d’un maintien et d’une réutilisation de composants pour des prestations métier proches.
Autre point de désaccord : les Facelets. Oui, il est certain qu’il s’agit d’un sacré piège au début en terme de récupération des erreurs, mais c’est paramétrable. Facelet amène en revanche une sacré performance comparé aux JSP et à leur phase de pré-compilation. On retrouve là les avantages que l’on peut trouver dans les différents moteurs de template (velocity etc…). En revanche, Facelets n’est pas là pour faciliter la conception de composants puisque cela se fait essentiellement au travers de la classe Renderer de JSF. Facelet améliore essentiellement les performances, puisque l’aspect composant est géré directement par le Framework. Je considère Facelet comme une manière d’améliorer les performances du Framework.
Concernant la scope request, j’en ai eu très peu l’utilité, mais certains cas que nous avons rencontré au sein de mon équipe n’auraient put-être réalisé sans l’utilisation du scope Request. Donc il est rarement utilisé mais peut parfois s’avérer salvateur pour répondre à certains besoins.
Enfin, en ce qui concerne le CPU, je suis en partie d’accord. C’est clair que JSF est gourmand, mais la lenteur, avant même le CPU, est du à la taille de la pile d’appel par laquelle passe la requête. Pour chaque composant, nous avons le schéma (simplifié) suivant : decode de tous les composants du dernier fils au premier père – action du managed bean – encode begin – encode children (donc du première père au dernier fils) – encode end. Je passe bien entendu outre les classes de tags et les classes UI qui rajoutent encore de nouveaux process. Et bien sûr, je ne parle pas des traitements accessoires qui pourraient survenir : validateur (au niveau du composant), listener (au niveau de la requête… ouille), intercepteur etc… Donc là dessus, c’est un sacré labeur. D’autant que le renderer peut-être exécuté plusieurs fois (un comportement dont je n’ai toujours pas compris l’intérêt même s’il n’a pas d’impact sur le résultat final puisque le résultat des parcours annexes n’est pas validé).
Enfin, voilà. Il s’agit de mon avis sur ce Framework que j’apprécie bien que je conçois tout à fait qu’il n’est ni le plus performant, ni le plus productif sur des prestations spécifiques.
Bonjour,
Je viens de lâcher l’éponge sur un projet prometteur dommage, il était en JSF1.2/facelets/tomahowk/Glassfish/EJB3. Trop long en développement, JSF m’a posé beaucoup de prise de tête, comme cité précédemment. Bugs, composants instables, problèmes d’intégration surtout.
On peut faire des choses magiques mais effectivement, il y a un prix à payer.
J’ai utiliser netbeans 6.1/6.5 a cela a été le bonheur, intégration de facelets et de tout le reste. Le top, la gestion du projet sous un fichier ant. Donc possibilité de le modifier sans que netbeans hurle. cerise sur le gâteau, il intègre maintenant PHP/python/etc … avec des plugins stables de netbeans. Pas besoins d’aller à la pêche comme Eclipse ;( . Bref, j’ai migré tous mes projets sous netbeans. Seul bémol, il a une fâcheuse tendance à indexer ses projet et cela pompe de grosses ressources.
Sinon, je m’intéresse à wicket, cela semble simple et efficace. j’avoue j’ai testé et je pense faire plus. Mais il semblerait que cela ne tienne pas la charge.
Dommage que Java n’offre pas un framework plus simple.
wicket ? grails ? je cherche …
olivier
Merci d’abord pour cette soluce : je l’avais déjà vu dans un de ces blogs
Sinon, y’a encore l’approche passive : attendre que le tooling FaceletsTools d’Eclipse soit prêt
Mince ca n’est pas passé, je réessaie
<jsp:root xmlns:jsp= »http://java.sun.com/JSP/Page »
xmlns= »http://www.w3.org/1999/xhtml »
xmlns:ui= »http://java.sun.com/jsf/facelets »
xmlns:f= »http://java.sun.com/jsf/core »
xmlns:h= »http://java.sun.com/jsf/html »>
<ui:composition>
<h:outputText value= »blabla »/>
</ui:composition>
</jsp:root>
En ce qui concerne la completion sous eclipse, tu peux essayer ceci :
Tu appelles tes pages .jspx (ou bien utilise l’editeur JSP).
Eclipse scanne automatiquement les .tld dans le classpath. Tu auras toutes les completions JSF et richfaces, mais tu n’auras pas celle de Facelets simplement parce qu’ils n’ont pas mis leur .tld dans leur jar… La solution est donc de l’ajouter soit même, et après jackpot
Facelets ne tient pas compte de ce qu’il y a autour de donc le jsp:root passera à la trappe.
Je suis globalement d’accord avec ce résumé de la technologie JSF.
Je trouve malheureusement que Sun ne fait pas assez d’efforts sur JSF, hélas.
Aujourd’hui, si on désire se lancer sur JSF, il est quasiment nécessaire d’ajouter les Facelets et une *vraie* librairie de composants, RichFaces en tête. Avec JSF « de base », on se limite pratiquement à écrire du « vieux » HTML, statique avec des composants bas de gamme…
La création de composants est également trop complexe, ce qui est dommage pour une framework orienté composants !
Dommage également que JSF 2.0 n’aille pas plus loin que ce qui est prévu.
Sinon, concernant les outils de développement, j’utilisais Exadel, mais avec la version 3.3 d’Eclipse, j’ai dû passer à JBossTools. C’est pas mal, ça donne le minimum de fonctionnalités pour travailler correctement avec JSF. Toutefois, pour peu que l’on utilise des composants de librairies externes (dont RF) ou des composants personnels, le développement par visualisation est complètement inutile. On se retrouve donc à coder du XML. On s’y fait, mais bon…
Bref, JSF est un très bel outil, mais qui pourrait vraiment être amélioré ! Pour JSF 3.0 ? (enfin si JSF tient jusque là).
@loic: Oui en effet, un retour d’expérience sur Wicket serait parfait
Pour ce qui est de Netbeans, je n’en ai pas la moindre idée: on l’avait pas utilisé dans ce projet.
Merci pour ce billet très intéressant!
Il serait intéressant d’avoir un retour d’expérience de ce type pour wicket, afin de voir si des défauts comparables à ceux de JSF apparaissent sur des gros projets (je n’ai testé JSF que sur des petits exemples et ca me paraissait presque parfait!).
Sinon, sans vouloir relancer des vieux débats, est ce que le niveau d’intégration de JSF avec netbeans est meilleur qu’avec Eclipse?