La concurrence entre les frameworks J2EE est grande et seule l’adoption par un plus grand nombre assure la pérennité de ces derniers. Struts 2 arrive avec l’ambition de remplacer Struts 1 qui est aujourd’hui le framework de référence pour la majorité des développements.
Plus qu’une évolution
Malgré le nom qui peut prêter à confusion, Struts 2 n’est pas une simple évolution de Struts 1. Il tire ses origines de deux framework J2EE, Struts 1 et WebWork.
- Le projet WebWork, à l’initiative de la société OpenSymphony, a vu le jour en mars 2002. Créé à partir du noyau Struts, le framework a évolué introduisant de nouveaux concepts et fonctionnalités, sans ce soucier de la compatibilité avec Struts. Contrairement à leurs attentes, cette solution alternative à Struts n’a pas rencontré un engouement très important au sein de la communauté J2EE.
- Struts 1 est un framework solide, largement éprouvé par le temps et plébiscité par un grand nombre. De ce fait, la compatibilité ascendante le freine dans ses évolutions. De nombreuses critiques se sont accumulées sans pouvoir être solutionnées dans l’état actuel des choses.
Face à ce constat, en décembre 2005 les équipes de Struts 1 et de WebWork ont mis en commun leurs compétences pour développer un nouveau framework baptisé WebWork2, renommé par la suite Struts 2, dont la première version stable est sortie le 22 février 2007, sous le label 2.0.6. Pour sa part, Struts 1 continue son évolution et est actuellement dans sa 8ème version officielle (1.3.8) depuis le 10 Mars 2007.
Comparaison des deux frameworks
Figure 1.1 : cycle de vie de Struts 1
Figure 1.2 : cycle de vie de Struts 2
L’architecture générale n’a pas changé. Cependant, les « ActionForm », une notion fondamentale dans Struts 1, ont disparu dans Struts 2 et se retrouvent directement intégrés aux classes d’action.
Pour accentuer la simplification, le passage obligatoire lors de l’appel d’une action par la méthode « execute » n’est plus systématique. En effet, Struts 2 autorise l’appel d’une action à partir de n’importe quelle méthode implémentée dans l’action.
Struts 1 fournit une classe abstraite « Action » et exige que toutes les classes d’action étendent cette dernière. Struts 2 apporte une solution à cette notion très critiquée en fournissant une interface d’action. Ainsi, les classes d’action sont libres d’hériter selon les besoins du projet d’une autre classe tout en implémentant l’interface d’action de Struts 2.
Au sein du cycle de vie de Struts 2, des intercepteurs ou des piles d’intercepteurs peuvent être configurés. Ils sont utilisés pour effectuer des pré/post traitements sur la requête.
Voici un exemple d’intercepteur utilisé pour vérifier la validité de l’authentification d’un utilisateur :
|
1 2 3 4 5 6 7 |
public class AuthenticationInterceptor implements Interceptor { public String intercept(ActionInvocation actionInvocation){ if (isAuthenticated(user)) return actionInvocation.invoke(); //Authentication OK else return Action.LOGIN; //Redirection sur la page de login } |
L’intercepteur est défini dans le fichier de configuration et est appliqué au sein de ce même fichier sur chaque action :
|
1 2 3 4 5 6 7 8 |
<interceptors> <interceptor name="authentication" class="project.interceptors.AuthenticationInterceptor"/> </interceptors> <action name="menu" class="project.actions.MenuAction"> <interceptor-ref name=" authentication"/> <result>menu.jsp</result> <result name="input">form.jsp</result> |
Struts 2 utilise la librairie xWork 2 pour effectuer une conversion de type et une validation entre le modèle de présentation et les classes d’action. Ainsi, toutes les erreurs de conversions classiques (String -> Long/Integer/Float/Boolean…) sont automatiquement gérées par cette librairie. De plus, des types de conversion spécifiques peuvent être créés en implémentant la classe abstraite « StrutsTypeConverter », facilitant ainsi le peuplement d’un bean à partir d’un formulaire. Pour accentuer cette simplicité, xWork 2 fournit une interface « ModelDriven » qui peut être implémentée par une action en fournissant le type d’objet à mapper. L’objet fourni est directement accessible dans la vue à l’aide du langage OGNL (Object Graph Navigation Language).
Voici un exemple concret d’un formulaire d’enregistrement d’une personne :
Définition de l’objet Personne :
|
1 2 3 4 5 |
public class Personne { private String nom; private String prenom; //getters/setters ... } |
Définition de l’action :
|
1 2 3 4 5 |
public class PersonneAction extends ActionSupport implements ModelDriven<Personne> { public String execute(){ return SUCCESS; } |
Définition de la JSP :
|
1 2 3 4 5 |
<%@ page contentType="text/html; charset=UTF-8"%> <%@ taglib prefix="s" uri="/struts-tags"%> <s:textfield name="model.nom" label="nom" /> <s:textfield name="model.prenom" label="prénom" /> <s:submit key="button.submit" value="Enregistrer" /> |
Au sein de la JSP, les attributs de l’objet « personne » sont directement passés en paramètre à travers le model. Avec le langage OGNL, « model.nom » représente à la fois le getter et le setter de l’attribut nom. De cette façon, l’étape de peuplement de l’objet est réalisée de manière transparente sans avoir besoin de passer par un « ActionForm » cher à Struts 1.
Conclusion
Struts 2 apporte principalement les réponses aux critiques faites à Struts 1. Cependant, même s’il s’appuie sur deux frameworks existants depuis longtemps, Struts 2 reste très récent et les bugs qui ne sont pas tous identifiés et par conséquent pas tous corrigés peuvent refroidir certains décideurs en matière de choix techniques pour leurs projets. De plus, le pari est risqué. En effet, qui peut prédire la longévité de ce framework face à une concurrence aussi rude. Struts 1 est loin d’être mort et sa popularité ne s’effacera pas de si tôt ! D’autre part, l’émergence des JSF constitue là un rival de taille.
Struts 2 a donc les moyens techniques pour convaincre, mais il doit aujourd’hui faire ses preuves et seule une communauté importante et active pourra imposer ce framework comme référence dans l’univers J2EE.