JSF, un remplaçant de Struts ?
Posté par Romain Linsolas, le 28/06/2007.Article paru dans la newsletter #20 – Ete 2007
Voici un deuxième article sur JSF. Il porte cette fois-ci sur la relation entre Struts et JSF. J’ai choisi ce sujet afin de tenter d’éclairer ceux qui se demandent s’ils doivent utiliser Struts ou JSF. Comme je le constate régulièrement en clientèle, cette question encore très courante est souvent l’objet de malentendus.
Dressons un rapide comparatif de ces deux frameworks.
Principes fondateurs
Struts est un framework qui permet de concevoir des applications Web Java selon le design pattern MVC (Modèle – Vue – Contrôleur) alors que JSF est dédié à la couche « Vue » de ce même modèle.
JSF est un standard, donc est supporté par l’industrie. Face à la multitude des frameworks MVC disponibles sur le marché, il s’agit là d’un argument non négligeable.
Struts est construit autour d’un puissant contrôleur. Celui-ci est puissant puisqu’il est possible de le personnaliser, grâce aux Actions.
Celui de JSF, beaucoup plus basique, n’est pas accessible : il est fourni uniquement afin de permettre une utilisation de l’API JSF seule.
JSF permet de manipuler de véritables composants graphiques. Son API permet de représenter des composants graphiques simples ou complexes, de gérer leur état et leur comportement. Il est même possible d’en créer de nouveaux ou d’en enrichir.
Struts ne permet pas une gestion aussi avancée des composants graphiques : cette notion n’existe pas réellement, elle est en général simulée par des custom tags, qui sont pratiques mais ne constituent pas un modèle de composants UI robuste.
JSF est construit sur un modèle événementiel simple. Grâce à la notion de composants côté serveur, JSF fournit un modèle qui définit comment gérer les événements générés par l’activation des composants côté client. Cette notion permet une gestion souple de l’état des composants.
Struts n’a pas cette notion de composants côté serveur, et donc encore moins de modèle de gestion des événements : l’activation de composants côté client déclenche l’exécution d’actions métier.
JSF propose un modèle de rendu séparé, c’est-à-dire qu’il sépare la définition et le rendu des composants. JSF fournit un modèle de rendu séparé qui définit comment les composants doivent être rendus en fonction des cas. En outre, ces composants ne sont pas destinés à être rendus exclusivement sur des pages Web.
Struts ne le permet pas car il n’a pas la notion de composants côté serveur : Struts propose une taglib pratique pour rendre des composants sans représentation côté serveur, et uniquement pour des pages HTML.
Struts permet la création de templates réutilisables. Le composant Tiles fourni par Struts permet de créer aisément des templates réutilisables par de nombreuses pages, donc de créer une charte graphique commune.
Struts inclut un framework de validation puissant : Le framework Validator de Struts inclut un grand nombre de validateurs standard, côté client ou côté serveur, personnalisables via des fichiers de configuration.
Conclusions
Le comparatif présenté précédemment nous suggère non pas d’utiliser Struts OU JSF, mais Struts ET JSF. L’idée est donc d’utiliser :
- JSF pour son modèle de composants.
- Struts pour son contrôleur, ses mécanismes de validation côté client et son framework Tiles.
Mise en œuvre
Le plus simple est de n’utiliser qu’un seul des deux frameworks. Mais les caractéristiques de Struts et tout ce qui a été publié à son sujet en ont fait un modèle mature de facto d’applications Web J2EE. Il s’agira donc très souvent d’intégrer JSF dans une application basée sur Struts.
Ce travail est facilité par la taglib d’intégration Struts-Faces. Son objectif est d’opérer une migration page par page en apportant des changements minimaux sur la configuration de Struts, mais aucun sur le back-end. En pratique, si ces modifications semblent mineures, elles imposent un jonglage entre les philosophies des deux framework : il s’agit de concevoir des contrôleurs en fonction d’événements sur des composants (click, focus, blur, change, etc.) et non plus des contrôleurs basés sur des traitements métier (create, update, delete, etc.) La migration n’est donc pas si simple que cela !
Shale, une solution ?
Il y a environ deux ans et demi, l’équipe Apache Struts a créé un sous-projet nommé Shale, initié par Craig McClanahan, leader des projets Struts et JSF.
Shale n’est pas un fork ou une évolution de Struts, c’est un nouveau framework MVC pour applications Web. Il reprend les objectifs de Struts mais repose sur les technologies qui n’existaient pas au lancement de ce dernier, comme JSF.
Shale n’en est qu’à ses débuts, il est donc trop tôt pour tirer des conclusions factuelles sur sa pertinence face au problème posé. Il a cependant le mérite d’en offrir une nouvelle perspective puisque contrairement à Struts qui peut s’intégrer avec JSF, Shale est basé sur JSF.
Références
Un article de Craig McClanahan sur la relation entre Struts et JSF :
http://blogs.sun.com/craigmcc/date/20040927#struts_or_jsf_struts_and
Un article de Craig McClanahan sur l’intégration de JSF dans une application basée sur Struts :
http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk8.html
Le site officiel du projet Apache Shale :
http://shale.apache.org
Tags: Web