Introduction au framework Struts Jakarta
Le développement d’applications Web était simple auparavant : il y avait une page HTML et un navigateur. C’était tout. Pas de données dynamiques, pas d’applications e-business, pas de maux de crâne. Mais cette simplicité n’a duré qu’un temps. Aujourd’hui nous sommes confrontés au développement d’applications Web et e-business compliquées reposant sur une pléthore de technologies.
Cet article se concentre sur un des aspects de ce processus de développement : comment utiliser le framework Struts dans l’intégration de front-end (NDT : portion de programme responsable de l’interface utilisateur). Struts est un cadre de travail (framework) open source développé pour encourager une architecture applicative basée sur le modèle conceptuel Model-View-Controller (MVC), très utile dans la construction d’applications Web reposant sur la technologie des Servlets Java et des Pages Serveur Java (Java Server Pages - JSP).
Cet article suppose une connaissance du fonctionnement des JSP, des servlets, des librairies de balises personnalisées (custom tag libraries), et d’XML. Référez-vous à mes précédents articles relatifs au développement de librairies de balises personnalisées JSP si vous sentez le besoin de réviser les aspects basiques. Ce tutoriel sera le premier d’une série à trois épisodes sur l’utilisation du cadre de travail Struts.
Au commencement
Struts est un framework Model-View-Controller (MVC) compatible avec la plate-forme J2EE de Sun et principalement basé sur la technologie des servlets et du JSP. Le framework Struts est apparu depuis maintenant une année à peu près et a été orginellement conçu par Craig McClanahan. Struts fait maintenant partie du projet Jakarta (mené par l’ASF, l’Apache Software Foundation). L’adresse offcielle de Struts est http://jakarta.apache.org/struts. Le framework a gagné une attention considérable dans les cours de l’année dernière du fait de sa simplicité d’utilisation et de sa capacité à répondre aux besoins des développeurs actuels en termes de création d’applications et en terme de rapidité de mise en oeuvre. Struts est une combinaison des servlets Java, des JSP, des balises personnalisées et des ressources message qui forme une ossature unifiée et évite au développeur de coder une modèle MVC complet, une tâche très lourde en vérité.
Le package Struts, même s’il n’en est qu’à sa révision 1.0, comporte une documentation complète. Vous y trouverez un guide utilisateur tout comme des guides pour développeurs. Si vous êtes un programmeur JSP débutant ou n’êtes pas aguerris de la conception des modèles MVC, cela pourrait constituer un gros morceau à avaler au départ, mais vous atteindrez vitre un rythme de croisière.
Une chose importante à noter : bien que ce ne soit qu’une version 1.0 du produit, il est extrêmement stable. J’utilise le framework Struts depuis la version 0.9 (j’ai récemment effectué la mise à jour en 1.0) sur un projet client à grande échelle, et n’ai jamais rencontré de problèmes avec. En fait, il a permis à nos équipes d’économiser une quantité importante de temps d’ingénierie dans les interactions complexes d’écrans de ce projet particulier. Bravo aux développeurs qui ont participé à ce projet Struts.
Une autre chose importante à signaler : si vous venez juste de démarrer avec ce framework, la mailing liste de Strut est très active et se trouve aux côtés des autres projets Jakarta open-source à l’adresse : http://jakarta.apache.org/site/mail.html.
A propos du Framework
Le framework en tant que tel peut être divisé en quatre parties principales, trois d’entre eux correspondant merveilleusement au modèle MVC :
- Le modèle, qui est un classe Action (dont nous parlerons dans une minute), subvient à la logique business écrite par le développeur. La distribution effectuée par le contrôleur à la classe Action est basée sur une configuration qui est prodiguée par le fichier struts-config.xml.
- La vue, qui est un ensemble de librairies JSP de balises personnalisées, travaille en concert avec la servlet du contrôleur et cela permet la création rapide de formulaires pour une application.
- Le contrôleur,qui est une servlet, distribue les requêtes reçues à la classe Action appropriée.
- Un nombre de classes utilitaires supportent l’analyse XML, l’enrichissement automatique des propriétés des JavaBean et l’internationnalisation des messages affichés.
Examinons les différentes parties du framework et prenons la mesure de l’interaction entre les objets dud système.
Configuration
Avant de pouvoir utiliser Struts, vous devez régler votre container JSP de façon à ce qu’il sache comment guider toutes les requêtes appropriées comprenant une certaine extension de fichier vers la servlet Struts d’action. Cela s’effectue dans le fichier web.xml qui est scruté au moment où le container JSP démarre. Alors qu’il est possible de définir plusieurs contrôleurs dans le fichier web.xml, un fichier pour chaque application devrait suffire. Nous aborderons plus en détail le fichier struts-config.xml quand nous parlerons de la classe Action.
<web-app>
<servlet>
<!--
Declare the OreillyAction servlet to be of type ActionServlet from the framework.
Include the configuration file as defined in the config param.
Set the debug level to 2 with a detail of 2 when loading the servlet.
Create 2 instances.
-->
<servlet-name>OreillyActionServlet</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<!--
All incoming requests that end in .action, send to the OreillyActionServlet.
-->
<servlet-mapping>
<servlet-name> OreillyActionServlet </servlet-name>
<url-pattern>*.action</url-pattern>
</servlet-mapping>
<!--
Send initial requests to the login page for this application
-->
<welcome-file-list><welcome-file>login.jsp</welcome-file></welcome-file-list>
<!--
Make all of the necessary related Struts JSP custom tag libraries
available and define where to find them.
-->
<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-html.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-logic.tld</taglib-location>
</taglib>
</web-app>
OreillyActionServlet
Le Contrôleur
Le contrôleur est vraiment l’agent de la circulation du framework et c’est lui qui détermine à quel moment les choses arrivent. La servlet contrôleur est responsable du packaging et du routage des requêtes HTTP vers l’objet approprié du framework. Ce rôle est pris en charge soit par une page JSP, soit par une classe Action.
Le contrôleur est inclus dans le fichier web.xml sous forme d’instance de la classe org.apache.struts.action.ActionServlet. L’exemple du dessus illustre ce qu’est la OreillyActionServlet. Au moment de son initialisation, le contrôleur parcourt un fichier de configuration (struts-config.xml) qui spécifie comment sont aiguillées les actions d’une application, ainsi que d’autres choses dont nous parlerons plus tard. Le contrôleur utilise alors ces spécifications pour déterminer où envoyer les requêtes HTTP. L’action de l’application prend alors le relai et effectue ce que la logique du business lui dicte de faire. Un aspect important est que les objets Action ont accès aux méthodes de la servlet. Cette une fonctionnalité puissante car quand un objet Action passe la main à un autre objet, un ou plusieurs objets partagés peuvent être transmis en les ajoutant à l’une des collections standard partagées par les servlets Java.
Le Modèle
Le modèle est un objet qui prend la requête d’un utilisateur et stocke les résultats pour toute la durée du process. Habituellement, un JavaBean se charge de passer l’information dans le process. Typiquement, les objets modèles sont spécifiques à l’application du fait qu’ils représentent basiquement la logique business de l’application. Struts fournit les classes ActionForm et Action, qui permettent la création d’objets modèles. C’est dans ces objets modèles que prend place la validation de formulaire ou de tout type de préparation de données de requêtes nécessaires. Il est possible d’avoir une relation un-pour-un entre les objets modèles et les pages de requêtes, mais cela n’est pas nécessairement requis. Il est aussi possible de réutiliser un objet modèle pour plusieurs pages de requêtes. Si aucune action n’est requise pour un objet modèle, le contrôleur peut transmettre la requête directement à l’objet vue, comme spécifié dans le struts-config.xml.
Struts-config.xml
Le fichier struts-config.xml est le véritable ciment du framework. Alors que web.xml définit où doit être dirigée une requête à son arrivée, struts-config.xml détermine exactement ce qui lui arrivera. C’est le Vito Corleone du framework Struts; rien ne se passe sans son accord et sa mise au courant. C’est à cet endroit que l’aiguillage des actions est défini. Comme avec le nombre croissant de fichiers de configuration XML, l’avantage d’en utiliser un tient dans le fait de garder un système modulaire et facile à maintenir. Cela évite de coder en dur les objets à appeler à l’intérieur d’un composant. Les changements peuvent être opérés à la volée en modifiant les fichiers de configuration sans avoir à redéployer les applications.
Le contrôleur utilise le fichier struts-config.xml pour déterminer quel objet appeler pour une requête donnée. Le fichier est lu au démarrage et les relations sont stockées en mémoire pour une performance optimale. Un struts-config.xml minimaliste est montré ci-dessous. Il ne définit qu’une action d’identification de manière à ce qu’à l’arrivée d’une requête d’identification elle soit passée à une instance de l’objet action com.oreilly.ui.authentication.actions.LoginAction. En retour de cette classe la page vers laquelle se diriger sera alors connue. L’exemple illustre aussi la possibilité de faire suivre à d’autres objets modèles; sinon, on retourne à l’objet vue, le fichier login.jsp dans ce cas.
<?xml version="1.0" encoding="ISO-8859-1" ?><!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.0//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">
<struts-config>
<!-- ========== Définitions des aiguillages d'actions ============ -->
<action-mappings>
<!-- Attributs de l'élément <action> -->
<!-
type - Nom complet de la classe Java d'implémentation des Actions
utilisé par cet aiguillage.
name - Nom du bean formulaire défini dans le fichier de configuration que cette action utilisera
path - Le chemin d'accès URI de la requête qui est assorti pour sélectionner ce mapping
unknown - Positionner à "true" si cette action doit être configurée comme étant
l'action par défaut pour cette application pour gérer toutes les requêtes non gérées par
d'autres actions.
Une seule action peut être définie comme action par défaut dans une application.
validate - Positionner à "true" si la méthode validate() de l'action associée à ce mapping
doit être appelée.
-->
<!-- ~~~~~~~~~~~~~~~~~~~~~ -->
<!-- O'Reilly Main Actions -->
<!-- ~~~~~~~~~~~~~~~~~~~~~ -->
<action path="/Login" type="com.oreilly.ui.authentication.actions.LoginAction">
<forward name="success" path="/DisplayMainPage.action"/>
<forward name="failure" path="/login.jsp"/>
</action>
</action-mappings>
</struts-config>
La vue
L’objet vue est souvent une page JSP. Le framework Struts ne fournit pas actuellement de JSP mais il fournit par contre de nombreuses librairies de balises qui permettent une intégration aisée de JSP dans le framework. L’interaction de Struts avec JSP permet le stockage de données d’un formulaire de saisie dans un bean formulaire; c’est l’ActionForm que nous avons mentionné plus haut. L’ActionForm est donc utilisé par la classe Action pour la validation de champs de saisies. Si des erreurs sont détectées durant cette phase de validation, un mécanisme partagé et disponible dans le framework se charge d’afficher les messages d’erreurs.
Le framework Struts comprend de nombreuses librairies de balises personnalisables, qui sont utilisées de différentes manières. Bien que leur utilisation ne soit pas requise pour utiliser le framework, il y a des chances que vous souhaiterez les explorer. Ces librairies comprennent :
- Librairie de balises n struts-html - utilisée pour créer des interfaces utilisateurs et des formulaires dynamiques en HTML.
- Librairie de balises n struts-bean - fournit des améliorations substancielles à la fonctionnalité basique prodiguée par <jsp:useBean>.
- Librairie de balises n struts-logic - peut gérer la création conditionnelle d’affichage de texte, le parcours en boucle d’une suite d’objets en vue de générer des affichages textes répétitifs et les flux de données de l’application.
- Librairie de balises n struts-template - contient des balises utiles pour la création de modèles dynamiques de JSP pour les pages qui partagent un format commun.
De plus, les balises personnalisées du framework Struts utilisent les fonctionnalités de localisation linguistique propres à la plate-forme Java en se servant de fichiers de ressources. Pour afficher des messages dans une autre langue, vous n’avez qu’à ajouter un fichier de ressources supplémentaire.
Migrer vers Struts
Le framework Struts, bien que relativement récent, tient bon de plus en plus auprès des développeurs. On le retrouve dans de nombreuses applications et il peut vous aider sur de nouveaux développements ou des projets JSP existants sur lesquels vous serez amenés à travailler.
Par exemple, au sein d’une application reposant sur une bases de données importantes telle que celle sur laquelle je travaille en ce moment pour un client, les beans de la logique business sont implémentés sous forme de EJB. Un JSP est affiché dans le navigateur. En fonction du formulaire affiché, une action spécifique prend place comme défini dans le fichier struts-config.xml. La classe action appropriée reçoit la requête, effectue quelques contrôles sur l’objet formulaire, puis appelle la méthode d’exécution du bean EJB approprié. Les résultats provenant du EJB sont retournés au format XML qui est alors analysé. Le contenu est stocké dans un bean formulaire puis affiché par un JSP.
Le complet contrôle du flux est effectué par le fichier struts-config.xml, en fonction des différentes valeurs retournées par les diverses classes action. Tout est localisé de manière centrale et facile à ajuster. Ni la servelt de l’action, ni le JSP n’ont besoin de connaître (et ne devraient s’en soucier dans un projet à n tiers participants) d’où proviennent les résultats qui sont affichés.
Le seul inconvénient que j’ai trouvé dans le framework dans mon projet actuel est ceci : compte tenu que c’est un projet à grande échelle, il y a beaucoup d’écrans et de types de requêtes différents. De ce fait, il y a beaucoup de classes Action puisque nous en avons besoin d’une seule par type de requêtes. Ceci pourrait être éviter par une planification consciencieuse en amont, mais le développement de nouveaux produits il n’est pas toujours possible d’identifier les requêtes communes. Cette information est acquise par la suite alors que l’application prend forme et c’est alors que les nouveaux besoins en terme de business sont définis. Bien sûr, il n’y avait pas beaucoup d’exemples Struts à suivre six mois auparavant. Ce problème mis de côté, Struts nous a aidé à économiser le temps qui aurait été nécessaire pour coder un modèle MVC complet, et a été vraiment assez stable pour s’en servir et en tirer bénéfice en production.
Dans la deuxième partie de cette série, nous parcourerons ensemble les phases de conception d’une application Struts simple et relierons ensemble toutes les parties dans un bout de code.
Textes originaux en anglais sur O’Reilly - ONJava.com : JSP and Servlets technologies par Sue Spielman
Chargement
Commentaires récents