Framework Struts

Transcription

Framework Struts

http://www.labo-sun.com
labo[email protected]
Framework Struts
Modèle MVC
Auteur : Hélène Semere Joui Cyril
Version n° 0.1 – D février YYYY
Nombre de pages : 57
Ecole Supérieure d’Informatique de Paris
23. rue Château Landon 75010 – PARIS
www.supinfo.com
Framework Struts – Modèle MVC
http://www.labosun.com
Ce document est la propriété de Supinfo et est soumis aux règles de droits d’auteurs
2 / 57
3 / 57
Table des matières
1. INTRODUCTION .....................................................................................................................................
6
1.1. PRÉSENTATION DE LA PLATEFORME J2EE .....................................................................................................
6
1.2. QUELQUES RAPPELS ..................................................................................................................................
6
1.2.1. Des Servlets aux JSP .....................................................................................................................
6
1.2.2. Dans la JSP : JavaBeans et TagLib ..............................................................................................
7
1.2.3. Définition et intérêts d’un framework de présentation ..................................................................
7
2. DESIGN PATTERN MVC .......................................................................................................................
9
2.1. MODÈLE MVC (MODEL VIEW CONTROLLER) ..............................................................................................
9
2.2. MODÈLE MVC2 ....................................................................................................................................
10
3. QU’EST CE QUE STRUTS ? ................................................................................................................
11
3.1. PRÉSENTATION ........................................................................................................................................
11
3.2. ARCHITECTURE .......................................................................................................................................
11
3.2.1. Cycle de vie d’une requête http ...................................................................................................
11
3.2.2. Vue d’ensemble d’une application struts .....................................................................................
12
3.2.3. Packages principaux ...................................................................................................................
12
3.2.4. Librairies dépendantes ................................................................................................................
12
3.3. LES MODÈLES : MODÉLISATION MÉTIER ........................................................................................................
13
3.3.1. Classe métier ...............................................................................................................................
13
3.3.2. Exemple de composant Modèle ...................................................................................................
13
3.4. LES VUES ..............................................................................................................................................
14
3.4.1. Les Taglib Struts ........................................................................................................................
14
3.4.1.1. StrutsHtml .........................................................................................................................................
15
......
3.4.1.2. StrutsLogic ............................................................................................................................................
15
..
3.4.1.3. StrutsBean .........................................................................................................................................
16
......
3.4.1.4. StrutsNested ......................................................................................................................................
17
......
3.5. LE CONTRÔLEUR .....................................................................................................................................
17
3.5.1. Servlet Générique : Classes d’action Struts ................................................................................
17
3.6. L’INTERNATIONALISATION .........................................................................................................................
19
3.6.1. Les fichiers « Properties » ...........................................................................................................
19
3.6.2. Outils Struts ................................................................................................................................
19
3.7. LE TRAITEMENT DES ERREURS ....................................................................................................................
20
3.8. FICHIER DE CONFIGURATION ......................................................................................................................
20
3.8.1. Assemblage de l'application ........................................................................................................
21
3.8.2. Datasources ................................................................................................................................
21
3.8.2.1. Exemple ...................................................................................................................................................
. 22
3.8.2.2. Utilisation dans l’application .................................................................................................................
23
..
3.8.3. FormBeans ..................................................................................................................................
23
3.8.3.1. Exemple ...................................................................................................................................................
. 24
3.8.4. Exceptions ...................................................................................................................................
24
3.8.4.1. Exemple ...................................................................................................................................................
. 24
3.8.5. Global Forwards .........................................................................................................................
25
3.8.5.1. Exemple ...................................................................................................................................................
. 25
3.8.6. Action mappings ..........................................................................................................................
25
3.8.6.1. Exemple ...................................................................................................................................................
. 26
3.8.7. Controller ....................................................................................................................................
27
3.8.7.1. Exemple ...................................................................................................................................................
. 28
3.8.8. Messageresources ......................................................................................................................
28
4 / 57
3.8.8.1. Exemple ...................................................................................................................................................
. 28
3.8.9. Plugin ........................................................................................................................................
28
3.8.9.1. Exemple ...................................................................................................................................................
. 29
3.9. INTÉGRATION AVEC L’APPLICATION WEB .....................................................................................................
29
4. LES TILES ...............................................................................................................................................
31
4.1. PRÉSENTATION ........................................................................................................................................
31
4.2. ARCHITECTURE .......................................................................................................................................
31
4.3. INSTALLATION ........................................................................................................................................
32
4.4. FICHIER DE CONFIGURATION ......................................................................................................................
32
4.4.1. Balise racine ...............................................................................................................................
32
4.4.2. Balise definition ..........................................................................................................................
33
4.4.3. Balise put ....................................................................................................................................
33
4.4.4. Balise putList ...............................................................................................................................
34
4.4.5. Balise item ...................................................................................................................................
34
4.4.6. Balise bean ..................................................................................................................................
35
4.4.7. Balise setproperty ......................................................................................................................
35
4.5. LAYOUTS ...............................................................................................................................................
36
4.5.1. Le fichier de structure .................................................................................................................
36
4.6. TILES ....................................................................................................................................................
38
4.7. EXEMPLE D’ARCHITECTURE DE DÉFINITIONS ..................................................................................................
38
5. VALIDATOR & FORMULAIRES .......................................................................................................
40
5.1. PRÉSENTATION ET ARCHITECTURE ...............................................................................................................
40
5.2. FICHIERS DE CONFIGURATION .....................................................................................................................
40
5.2.1. Dans le fichier strutsconfig.xml .................................................................................................
40
5.2.2. Le fichier validatorrules.xml : ...................................................................................................
41
5.2.3. Le fichier validation.xml : ..........................................................................................................
42
5.3. DYNAFORMS ..........................................................................................................................................
46
5.4. RÉSUMÉ DE LA CONFIGURATION DES VALIDATORS ........................................................................................
49
6. INTÉGRATION AVEC XDOCLET .....................................................................................................
50
6.1. STRUTSCONFIG.XML ................................................................................................................................
50
6.1.1. Tags @Struts ...............................................................................................................................
50
6.1.2. Exemples .....................................................................................................................................
52
6.1.3. Intégration avec Ant ....................................................................................................................
53
7. CAS CONCRET (ARCHITECTURE) ..................................................................................................
55
7.1. PRÉSENTATION ........................................................................................................................................
55
7.2. ARCHITECTURE .......................................................................................................................................
55
7.3. COUCHE MÉTIER ......................................................................................................................................
55
7.3.1. Couche d’accès aux données (DAO) ...........................................................................................
55
7.3.2. Couche service ............................................................................................................................
55
7.4. COUCHE APPLICATION ..............................................................................................................................
55
7.4.1. Action ..........................................................................................................................................
55
7.4.1.1. ActionForm ..................................................................................................................................
55
............
7.4.2. Forwards .....................................................................................................................................
56
7.4.3. Exceptions ...................................................................................................................................
56
7.5. COUCHE PRÉSENTATION ............................................................................................................................
56
7.5.1. Tiles .............................................................................................................................................
56
7.5.1.1. Définitions ...........................................................................................................................................
56
.....
7.5.1.2. Jsp (layouts et tiles) ...........................................................................................................
56
......................
7.5.2. Formulaires .................................................................................................................................
56
5 / 57
7.5.3. Messages d’erreur (MessageApplication) ...................................................................................
56
8. L’AVENIR DE STRUTS ........................................................................................................................
57
8.1. INTÉGRATION AVEC JSTL ........................................................................................................................
57
8.2. INTÉGRATION AVEC JSF ...........................................................................................................................
57
8.3. ADOPTION GÉNÉRALISÉE DE STRUTS ...........................................................................................................
57
6 / 57
1.Introduction
1.1.Présentation de la plateforme J2EE
J2EE (Java 2 Enterprise Edition) est un ensemble d'APIs visant le développement d'applications orientées entreprise. Parmis ces APIs, certaines existent déjà dans la version "standard" de Java (Java 2 Standart Edition), tandis que d’autres ne sont présentes que dans la version orientée entreprise. Ainsi on a les APIs EJBs (Enterprise Java Beans) ou JMS (Java Message Service) qui sont spécifiques au jdk J2EE, à l’inverse des APIs JDBC ou RMI qui existent aussi dans le jdk J2SE.
La plateforme J2EE présente une solution optimale pour développer des applications robustes, sécurisées et évolutives. En effet, choisir cette technologie, c’est suivre un certain nombre de règles. Le but est en effet de séparer au maximum l’application en couches.
Ce que l’on va justement détailler dans ce cours est de quelle manière on va découper les différentes couches, quel modèle utiliser, et avec quels outils le faire.
1.2.Quelques rappels Avant de commencer ce cours, quelques rappels sur les JSP/Servlets, les JavaBeans ainsi que les TagLib :
1.2.1.Des Servlets aux JSP
Lorsque l’on va développer un site Web à l’aide des technologies J2EE, on peut difficilement passer à côté des Servlets.
Une Servlet est une classe java chargée une seule et première fois par le moteur de Servlet (exemple : Tomcat) lors de son premier appel. Par la suite, on fera toujours appel à la même instance de cette Servlet.
Chaque fois que l’on va créer une Servlet, on créera une classe implémentant l’interface Servlet et donc redéfinir quelques méthodes dont les méthodes •
•
•
public void init(ServletConfig cfg) qui sera appelée lors du premier appel de la Servlet, lors de son instanciation.
public void service(ServletRequest req, ServletResponse res) qui sera appelée à chaque appel de la Servlet instanciée.
public void destroy() qui sera appelée juste avant la destruction de la Servlet.
Ainsi, c’est dans la méthode service() que va se trouver le code java dont le résultat, envoyé au browser, permettra l’affichage sur une page Web.
7 / 57
Le problème est que si l’on suit ce principe, la partie traitement de notre code est mêlée à la partie présentation alors que, comme il l’a été précisé précédemment, les bases même d’une application utilisant les technologies J2EE est le découpage en couches.
Pour séparer clairement la partie traitement de la partie présentation de notre application, on va donc utiliser les pages JSP. Une page JSP ressemble à une page HTML pouvant contenir des balises JSP et/ou du code Java. Elle va donc nous permettre d’afficher les résultats des traitements effectués en arrière plan dans des classes Java. Dans ce cas, la page JSP va être convertie en Servlet puis le processus va être le même que pour une Servlet classique.
1.2.2.Dans la JSP : JavaBeans et TagLib
Dans notre page JSP, on va pouvoir utiliser différents composants pour afficher les différents résultats des traitements effectués dans les couches inférieures.
Les JavaBeans sont des composants qui vont permettre d’instancier et manipuler différents objets Java (à portée de la page, de requête, de session ou de l’application) à l’aide de balises JSP. L’avantage est que lorsqu’il va rencontrer une balise, le serveur va automatiquement détecter si l’instance de l’objet existe déjà ou non. Si c’est le cas, il reprend l’instance existante sinon il en crée une nouvelle. Cela va permettre d’utiliser un même objet sur plusieurs pages, voire tout le long de l’application.
Les TagLibs, tout comme les JavaBeans sont des composants qui vont permettre d’instancier et manipuler différents objets Java à l’aide de balises JSP. Cependant, ils ne pourront avoir qu’une portée limitée à la page courante. On ne pourra donc pas réutiliser une même instance d’un objet sur plusieurs pages. Pour chaque page de l’application, on aura une instance différente. Les TagLibs, balises personnalisées, vont permettre, entre autres de créer ses propres balises de la plus simple à la plus complexe et ainsi d’afficher les résultats des différents traitements en quelques lignes.
Pour plus d’informations sur ces composants, n’hésitez pas à consulter le cours sur les Servlets/JSP.
1.2.3.Définition et intérêts d’un framework de présentation
On a donc pu voir que les JSP offrent une solution idéale pour afficher les résultats des traitements effectués en amont. Ils représentent la partie présentation de notre application. On a aussi vu que l’on pouvait utiliser les JavaBeans ou les TagLibs pour éviter d’avoir du code Java dans nos pages JSP.
Cependant, l’objectif premier d’un développeur est d’éviter de refaire chaque fois la même chose. Pour cela, on va utiliser un framework qui impose une méthode de développement simple et efficace. http://www.labosun.com
8 / 57
On va alors obtenir une application respectant les objectifs de réutilisabilité que vise la programmation orientée objet.
Concrètement, un framework est le squelette d’une application. Cela va permettre la création rapide d’actions/événements classiques, par exemple, un formulaire (tenant compte de la sécurité, de la validité, etc…).
Quels que soient les outils utilisés dans les couches inférieures, le framework de présentation choisi est complètement indépendant. Il nous permet donc d’atteindre l’objectif attendu ; des couches complètement indépendantes les unes des autres. On peut alors changer l’une des d’elles sans modifier les autres.
9 / 57
2.Design pattern MVC
2.1.Modèle MVC (Model View Controller)
Le pattern ModèleVueContrôleur est l’un des modèles les plus connus et le plus célèbre de tous. Il a été tout d’abord élaboré par Xerox lors de leur premier système fenêtré et plus particulièrement pour gérer les interactions avec l’utilisateur. Le problème que résout le modèle MVC est celui de la simplification de trois grandes fonctions communes à de nombreuses applications : •
La maintenance des données dans un stockage de backend ou sur un système distant.
•
La construction de la couche présentation destinée à l’utilisateur final.
•
La gestion de la logique conditionnelle qui décide des écrans qui sont présentés à l’utilisateur, de ce qui se passe lorsqu’une erreur survient et de la façon et du moment exacts où les systèmes distants sont mis à jour.
Il est donc possible de combiner l’ensemble de ces modules et d’avoir au final un système qui fonctionne. Cependant les problèmes se posent lorsque vous souhaitez maintenir le code. En effet dans le cas des JSP, les concepteurs HTML chargés du look end feel et ceux qui maintiennent le code de traitement sont différents.
MVC traite ce problème en séparant le code en trois parties distinctes : •
Les composants Modèle, qui maintiennent les données dans le stockage.
•
Les composants Vue, qui constituent la couche présentation destinée à l’utilisateur final.
•
10 / 57
Les composants Contrôleur, qui gèrent la logique conditionnelle. C’est elle qui décide des écrans qui sont présentés à l’utilisateur, qui gère les erreurs et la mise à jour des systèmes distants.
MVC simplifie donc la maintenance de l’application et empêchent les trois types de logiques de se mélanger. Il permet également de masquer les détails d’implémentation de chaque domaine aux deux autres et réduit ainsi les dépendances de codage entre eux. De ce fait, MVC permet de définir une frontière naturelle entre les concepteurs web qui maintiennent le code html et la couche présentation.
Un des avantages considérable dans le développement d’application web (jsp, servlet) est que le modèle MVC facilite grandement la gestion des exceptions (car elles sont toutes gérées via le contrôleur).
D’autres avantages s’appliquent à toutes les formes de traitement conditionnel. Voici quelques exemples : •
Si différentes Vues sont nécessaires en fonction des données qui sont extraites d’une base de données ou d’un système distant, le Contrôleur peut décider de la page à présenter.
•
Si votre application change en fonction de l’heure et/ou la date de la journée, le Contrôleur peut gérer cela facilement.
•
Si un processus de saisie de données nécessite plusieurs pages, dont certaines sont facultatives.
Cependant le pattern MVC est clairement définit, pourquoi parleton parfois de MVC1, MVC2 ?
2.2.Modèle MVC2
Le modèle MVC2 n’a rien de plus que le modèle MVC. L’origine de ce nom vient du fait que Sun, lors de la sortie des spécifications JSP, indiquait dans une section « Page Access Model » (ou modèle d’accès JSP) un modèle1 et un modèle2.
Le modèle1 décrivait le traitement JSP de la façon dont il était couramment utilisé à l’époque. C'estàdire la requête HTTP est directement envoyée vers un fichier jsp. Tout le traitement se faisait alors dans la page JSP, et la réponse venait de ce même fichier.
Le modèle2 était bien différent. Il indiquait que c’était la servlet qui devait recevoir la requête HTTP. Celleci pouvait alors effectuer les tâches nécessaires au traitement de cette requête (mémoriser des informations dans le bean transmis) et transmettre les informations à une page jsp afin que celleci génère la réponse HTTP.
Aucun nom de type « MVC » n’intervient dans ces modèles, cependant le modèle2 s’en inspire étroitement.
11 / 57
3.Qu’est ce que Struts ?
3.1.Présentation
Struts est un framework pour les applications web. Un framework est « une structure permettant de soutenir ou de contenir quelque chose, en particulier un squelette pouvant servir de base à une construction » (cf. dictionnaire anglais). Struts est en une collection de programmes Java conçue pour vous aider à construire des applications robustes en gagnant du temps. Il fournit la charpente et le gros œuvre de base. Il vous reste alors plus qu’à vous consacrer à l’agencement et à la décoration des pièces !
Outre que Struts vous permet de vous faire gagner du temps, il vous permet de voir des applications complexes comme une suite de composants de base : Vues, Actions, Modèles.
Il vous fournit un ensemble de bonnes pratiques et une base solidement réfléchie. De plus rien ne sert de réinventer la roue, Struts vous permet de partir d’une base solide, idéal pour les débutants !
Cependant Struts est principalement voué à être utilisé pour les applications web mais est complètement conforme à la spécification Servlet (actuellement 2.3) qui fait partie de la spécification plus large de J2EE.
L’un des autres avantages et que Struts est une solution OpenSource dont un grand nombre de développeurs contribuent activement.
3.2.Architecture
3.2.1.Cycle de vie d’une requête http
Navigateur de l utilisateur
1
Composant
Contr leur
2
Composant
Mod le
3
4
5
Composant
Vue
Stockage
Persistant
ou syst me distant
1. Le client envoie une requête à l’application
2. Le composant Contrôleur reçoit la requête. Il commence alors à prendre des décisions sur la façon de continuer, en fonction des règles de gestion de l’application.
3. Les composants Modèle agissent avec les stockages de données persistant.
12 / 57
4. Suivant les données retournées par le Modèle, le contrôleur détermine la Vue à utiliser pour l’affichage des données et lui transfert les données.
5. Le composant Vue choisi génère la réponse à la demande du client.
3.2.2.Vue d’ensemble d’une application struts
Trois parties principales constituent une application utilisant Struts : •
La librairie Struts et ses dépendances
•
Les classes Java : actions, formulaires, exceptions …
•
Le fichier de configuration strutsconfig.xml : assemblage de l’application (liaisons url, classes, formulaires, sources de données …)
3.2.3.Packages principaux
Voici une description générale des principaux packages de l’application : •
org.apache.struts : package root
•
org.apache.struts.action : package noyau des classes de bas niveau pour les Contrôleur
•
org.apache.struts.config : package représentant les éléments de configuration (que l’on retrouve également dans strutsconfig.xml)
•
org.apache.struts.taglib : package root de l’ensemble des taglib Struts
•
org.apache.struts.taglib.bean : package qui regroupe les classes de tag de la librairie Bean
•
org.apache.struts.taglib.html : package qui regroupe les classes de tag de la librairie Html
•
org.apache.struts.taglib.logic : package qui regroupe les classes de tag de la librairie Logic
•
org.apache.struts.taglib.nested : package qui regroupe les classes de tag de la librairie Nested
•
org.apache.struts.tiles : package du plugin tiles
•
org.apache.struts.upload : package des classes simplifiant l’upload avec Struts
•
org.apache.struts.util : package des classes utilitaires de Struts
•
org.apache.struts.validator : package du plugin validator
3.2.4.Librairies dépendantes
Voici l’ensemble des librairies qu’il faut intégrer à votre application web afin de pouvoir utiliser Struts : http://www.labosun.com
13 / 57
•
struts.jar : jar contenant le framework Struts (Actions, forms …)
•
commonsbeanutils.jar ; outils pour l’utilisation des Beans
•
commonsdigester.jar : mapping xml > objet java
•
commonsvalidator.jar : utilisé pour la gestion de la validation (Validator plugin)
•
commonslogging.jar : permet de faire des logs dans vos applications
•
commonsfileupload.jar : utilisé pour facilité l’upload de fichier •
struts(bean / logic / nested / html).tld : fichier de description des librairies de taglib Struts
3.3.Les modèles : modélisation métier
Un composant modèle représente généralement un objet métier ou un système de backend physique. Par exemple, un système qui permet à des utilisateurs de se connecter et de gérer des informations personnelles peut comprendre un composant Modèle qui représente un Utilisateur.
3.3.1.Classe métier
La classe métier fournit des méthodes qui permettent d’accéder aux informations lié à l’objet (par exemple pour l’utilisateur : nom, prénom, mot de passe …). Cependant les concepts de base sont les suivants : •
Les classes modèles servent à accéder aux informations mémorisées dans des bases de données ou sur des systèmes distants pour les présenter aux utilisateurs.
•
Elles doivent être conçues de manière à cacher les détails d’implémentation de l’accès à l’information (utilisation d’interface).
3.3.2.Exemple de composant Modèle
Dans le cas d’une application construite sur un conteneur de servlet (Tomcat), le composant Modèle peut se limiter à un simple bean Java fournissant une vue métier à une logique JDBC qui maintient les informations dans la base de données. Le reste de l’application interagit avec le Modèle pour lire et écrire les informations et seul le Modèle interagit avec la base de données.
Dans une application construite avec un système frontal utilisant JSP et un système dorsal auquel on accède via des WebServices, les composants Modèles servent à fournir une représentation métier du système dorsal. Le reste de l’application continue à accéder aux informations par l’intermédiaire du Modèle, mais seul celuici accède aux Web Services.
Cela est de même avec un système utilisant les EJB (cf. Entreprise Java Bean). Le Modèle assure l’accès aux EJB.
14 / 57
Cela permet donc une grande flexibilité pour l’évolution de l’application mais également une extrême puissance et souplesse pour les développeurs.
3.4.Les vues
Dans le pattern MVC, le composant Vue se concerne sur une seule chose : la création de la couche présentation que voit l’utilisateur. Ce composant ne doit contenir qu’un strict minimum de logique métier et d’analyse complexe.
Les composants Vues sont le plus souvent ceux associés à la réponse de la requête HTTP. Dans le cas de Struts ce sont les JSP qui représente le plus souvent cette vue. En effet, ces fichiers génèrent le HTML qui sera envoyé au client.
Un des avantages des JSP est que l’on peut tout aussi bien intégrer du HTML, des balises JSP ou encore des scriptlets Java dans un même fichier. Cependant l’inconvénient est que la tâche des concepteurs web en est alors complexifiée pour le maintient du look and feel ! De plus un développeur Java est trop facilement attiré par la tendance à abuser des scriplets et à inclure la logique métier (ou instructions conditionnelles) directement dans la JSP !
Avec le pattern MVC, ce problème est résolut car il isole le modèle, les traitements et la/les vues. De plus Struts fournit un ensemble de balises JSP personnalisées servant à construire les composants de la Vue. On retrouve des balises tels que : <html:text>, <logic:iterate> qui donnent aux développeurs Java et aux concepteurs web la possibilité de construire des fonctionnalités sans utiliser de scriplet Java.
3.4.1.Les Taglib Struts
Les balises personnalisées du framework Struts constituent une part importante. En effet, elle simplifie grandement le développement de page JSP (composant Vue) et les relient aux autres composants.
Ces balises vous permettront de débugger plus rapidement vos applications car leur nom et description sont un avantage considérable contrairement aux scriplets.
Les balises Struts sont regroupées en quatre groupes : •
Html : gère l’ensemble des balises html (champs texte, file …)
•
Logic : gère la logique de vos Vue (itération, condition …)
•
Bean : gère l’accès aux bean (et à leur propriétés) de votre application (page, request, session …)
•
Nested : regroupe html, logic, bean en ajoutant une arborescence pour l’accès au bean
Tous les descripteurs de ces bibliothèques sont inclus dans le framework sous le nom de : struts
<<type>>.tld. Par exemple : strutshtml.tld représente le descripteur de la bibliothèque html.
15 / 57
3.4.1.1.StrutsHtml
Cette bibliothèque est principalement utilisée pour la gestion des formulaires dans Struts. Cependant elle couvre la majorité des balises de base du HTML.
Voici le tableau récapitulatif des tags disponibles : Tag Name
base button cancel checkbox errors file form frame hidden html image img Description
Affiche la balise HTML <Base> Affiche un bouton
Affiche un bouton de cancel
Affiche une checkbox
Affiche l’ensemble des errors de traitement de la requête (champs non valides …)
Affiche un champ fichier
Définit une balise <form>
Affiche une frame HTML
Affiche un champ caché
Affiche un tag html
Affiche un champ image (formulaire)
Affiche une balise img
Affiche le contenu javascript permettant d’effectuer une validation côté client d’un javascript formulaire (utilisation avec le plugin Validator)
link Affiche une ancre HTML
messages Affiche l’ensemble des messages accumulés lors de l’exécution de la requête
multibox Affiche une checkbox
option Affiche un champ Option
options Affiche une collection d’options dans un tag Select
optionsCollection Affiche une collection d’options dans un tag Select
password Affiche un champ mot de passe
radio Affiche un bouton radio
reset Affiche un bouton de reset
rewrite Affiche une url lié au context en cours
select Affiche un champ Select
submit Affiche un bouton envoyer
text Affiche un champ texte
textarea Affiche un champ textarea (zone de texte)
xhtml Affiche un tag XHTML
3.4.1.2.StrutsLogic
Cette bibliothèque contient un ensemble de tags utilisés dans la gestion de condition, itération suivant des objets, et gestion de flux de l’application.
16 / 57
Tag Name
empty Description
Evalue le contenu du corps de la balise si la variable est null ou vide. Evalue si le contenu du corps de la balise si la variable est égale à la valeur equal spécifiée. forward Transfert le contrôle à la page spécifiée dans l’entrée ActionForward. Evalue le contenu du corps de la balise si la variable est plus grande ou égale à la greaterEqual valeur spécifiée. Evalue le contenu du corps de la balise si la variable est strictement plus grande greaterThan que la valeur spécifiée.
iterate Répète le contenu du corps de la balise suivant la collection spécifiée.
Evalue le contenu du corps de la balise si la variable est inférieure ou égale à la lessEqual valeur spécifiée.
Evalue le contenu du corps de la balise si la variable est strictement inférieure à la lessThan valeur spécifiée.
Evalue le contenu du corps de la balise si la valeur spécifiée est une sous chaine match appropriée de la variable. Génère le contenu du corps de la balise le message spécifique n’est pas présent messagesNotPresent dans la requête. Génère le contenu du corps de la balise le message spécifique est présent dans la messagesPresent requête.
Evalue le contenu du corps de la balise si la variable est ni null ou ni vide ni une notEmpty collection vide (testée par isEmpty() de l’interface Collection).
Evalue si le contenu du corps de la balise si la variable n’est pas égale à la valeur notEqual spécifiée.
Evalue le contenu du corps de la balise si la valeur spécifiée n’est pas une sous notMatch chaine appropriée de la variable.
Génère le contenu du corps de la balise la valeur spécifique n’est pas présente dans notPresent la requête. Génère le contenu du corps de la balise la valeur spécifique est présente dans la present requête.
redirect Ecrit un header HTTP Redirect dans la réponse.
3.4.1.3.StrutsBean
Cette bibliothèque est utilisée pour lire et écrire les données contenues dans des beans, voir même les bean euxmêmes, ou encore définir de nouveaux beans.
Tag Name
Description
cookie Définit une variable de script basée sur la valeur du cookie spécifié. define Définit une variable de script basée sur la valeur du bean spécifié.
header Définit une variable de script basée sur la valeur du header spécifié.
Charge la réponse depuis une application dynamique et inclut celleci dans un bean (type include String).
17 / 57
Tag Name
Description
message Affiche le contenu d’un message internationnalisé) dans la réponse.
page Expose un spécifique objet du context de la page à un bean. parameter Définit une variable de script basée sur la valeur du paramètre (requête) spécifié.
resource Charge une ressource demandée et inclut celleci dans un bean (type String ou InputStream).
size Définit une variable de script basée sur la taille d’une Collection ou Map spécifié.
struts Expose l’objet de configuration struts à un bean.
write Affiche le contenu d’une propriété d’un bean dans la page (out).
3.4.1.4.StrutsNested
Cette bibliothèque est un peu spéciale car elle regroupe les trois précédentes. Cependant elle permet de structurer vos tags suivant l’arborescence de vos beans.
Voici les trois tags supplémentaires : Tag Name
Description
nest Définit un nouveau niveau que les tag fils pourront utiliser. writeNesting Définit une variable de script basée sur le niveau courant. root Démarre une racine d’une hiérarchie.
3.5.Le contrôleur
Ce sont les composants qui mènent l’action ! Chaque fois qu’un utilisateur soumet un formulaire, c’est le contrôleur qui le traite. Si l’utilisateur demande une autre page, c’est lui qui décide de ce qui sera affiché. C’est également lui qui collecte les informations auprès des composants Modèle pour que les composants Vues aient les informations à afficher.
Voici un récapitulatif des actions effectuées par le Contrôleur : •
Valider les données saisies par l’utilisateur.
•
Prendre des décisions concernant les composants Modèle auxquels il faut accéder ou mettre à jour.
•
Récupérer les données pour le composant Vue.
•
Prendre des décisions concernant la façon de traiter telle ou telle erreur survenue durant le traitement de la réponse
•
Décider de la Vue à afficher
3.5.1.Servlet Générique : Classes d’action Struts
Le contrôleur est implémenté en deux parties : http://www.labosun.com
•
Java : classe d’action •
Struts : configuration xml
18 / 57
L’action reçoit les saisies utilisateur, coordonne l’accès au stockage persistant ou systèmes distants met en œuvre la logique de l’application et décide du composant Vue qui sera affiché ensuite à l’utilisateur.
Une classe d’action doit : •
Etendre la classe : org.apache.struts.action.Action ou une classe dérivée
•
Surcharger la méthode : public ActionForward execute(…) afin d’effectuer le traitement spécifique à l’action
•
Ne comporter aucun lien avec une page JSP directement (ce lien est effectué dans le fichier de configuration)
Cette classe d’action peut être très simple comme très complexe. Par exemple vous pouvez créer un lien qui dirige vers une classe d’action affichant un formulaire de création d’un nouveau compte utilisateur. La classe d’action s’apparentera à cela : package com.labosun.lessons.struts.action;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
public class NewAccountAction extends Action {
public ActionForward execute(ActionMapping mappings, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
return mappings.findForward("newUserForm");
}
}
Aucune référence au fichier jsp n’est faite. La configuration de cette action ressemblera à (cf. §3.8) : <action path="/addUser" type="com.labosun.struts.action.NewAccountAction" input="/home.jsp" scope="request" >
<forward name="home" path="/adduser.jsp"></forward>
</action>
Cependant la majorité des actions est bien plus complexe que celleci. Elles font des traitements d’accès aux données, mise à jour …
Voici l’ensemble des méthodes les plus utilisées de la classe Action : http://www.labosun.com
19 / 57
•
addErrors(javax.servlet.http.HttpServletRequest request, ActionMessages errors) : ajoute une erreur à la requête. L’ensemble des erreurs ajoutées pourra être affiché par l’intermédiaire de la balise : <html:errors/>
•
addMessages(javax.servlet.http.HttpServletRequest request, ActionMessages messages) : ajoute un message à la requête. L’ensemble des messages ajoutés pourra être affiché par l’intermédiaire de la balise : <html:messages/>
•
execute(ActionMapping
mapping,
ActionForm
form, javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) : méthode à surcharger afin d’effectuer le traitement spécifique pour l’action en cours. Retourne un objet de type ActionForward indiquant la vue (ou autre action) à laquelle on souhaite passer la requête.
•
setLocale(javax.servlet.http.HttpServletRequest request, java.util.Locale locale) : permet de récupérer la locale de l’utilisateur (utile pour savoir le pays/langue de celuici).
3.6.L’internationalisation
Struts met à disposition un ensemble d’outils permettant de gérer facilement l’internationalisation dans vos applications web.
Vous pouvez tout aussi bien utiliser l’internationalisation pour gérer les messages d’erreur de vos formulaires que pour vos messages d’une page JSP.
Dans Struts, on parle de bundle de messages pour indiquer un groupe de message dynamique. Un bundle est représenté par un fichier Properties (bien connu dans le monde Java).
3.6.1.Les fichiers « Properties »
Qu’est ce qu’un fichier Properties ? En java, il existe une classe : java.util.Properties qui permet de lire un fichier standardisé très simplement (un fichier properties).
Ce fichier prend généralement l’extension .properties et regroupe des groupes binaires (clé => valeur). Pour chaque valeur dynamique on associe une clé unique indépendante du langage ce qui permet de relier plusieurs valeurs à une même clé selon le langage en cours.
Voici un exemple de fichier Properties :
cle1=valeur1
cle2=valeur2
cle3=valeur3 3.6.2.Outils Struts
Struts utilise un bundle par défaut qui est lié au fichier : ApplicationRessources.properties. Cependant vous pouvez tout à fait personnaliser l’accès à ce fichier dans le fichier de configuration http://www.labosun.com
20 / 57
de Struts. Vous pouvez également scinder vos propriétés en plusieurs fichiers et donc plusieurs bundle.
L’utilisation principale se fera dans vos JSP par l’intermédiaire de la balise : <bean:message key=”cle0” />
Ou <bean:message key=”cle0” bundle=”nomDuBundle” />
Vous pouvez également récupérer la valeur d’un message directement dans une action : getResources(request).getMessage("cle");
3.7.Le traitement des erreurs
Struts vous permet de centraliser la gestion des exceptions liées au Contrôleur. Vous pouvez définir des liaisons entre le type d’exception et une page jsp (pour afficher un message). Vous pouvez également ajouter une classe handler qui est automatiquement appelée lorsqu’une exception est jetée.
Voici un schéma représentant le fonctionnement en globalité :
1
Classes Action (Contr leur)
<<Type>>Exception
2
3
Fichier
Config.
Classe Handler
h ritant de ExceptionHandler
4
JSP page erreur
1. Une classe d’action jette une exception de type : « Type »Exception
2. Struts détecte une configuration pour cette exception dans le fichier de configuration
3. Suivant cette configuration, Struts appelle la classe Handler pour cette exception
4. Struts redirige vers la page jsp d’erreur configurée
3.8.Fichier de configuration
Le fichier de configuration est le point central de toute application Struts. En effet, il regroupe l’ensemble des objets et de leur configuration. On peut connaître l’ensemble de la logique de l’application (navigation) avec ce fichier. Malgré la lourdeur d’utilisation de xml dans une application web complexe (suivant le nombre de fonctionnalités), les outils qui ont été mis en œuvre pour aider le développeur dans le paramétrage de ce fichier sont maintenant stables et robustes.
21 / 57
3.8.1.Assemblage de l'application
Le fichier de configuration : strutsconfig.xml (le plus souvent nommé ainsi) est chargé d’indiquer à Struts quels sont les formulaires, les actions disponibles et permet également d’ajouter un certain nombre de modèles « enfichables » au package Struts de base.
Nous étudierons ici l’ensemble des balises de bases utilisées dans une application Struts grâce à la DTD
fournit
par
Struts
à
l’adresse
suivante : http://jakarta.apache.org/struts/dtds/struts_config_1_2.dtd (DTD de la version 1.2).
La première balise que l’on retrouve dans le fichier de configuration est : « strutsconfig ». La dtd correspondante est celleci : <!ELEMENT strutsconfig (displayname?, description?, datasources?, form
beans?, globalexceptions?, globalforwards?, actionmappings?, controller?, messageresources*, plugin*)>
<!ATTLIST strutsconfig id ID #IMPLIED>
On l’appelle la balise « root », c'estàdire la racine de toutes les autres. On ne peut trouver qu’une seule de cette balise dans un même fichier. Il est aisé de voir qu’elle accepte (dans son corps) les balises : •
displayname : nom de l’application liée au fichier de configuration en cours
•
description : description du fichier de configuration
•
datasources : l’ensemble des sources de données (1 instance acceptée)
•
formbeans : l’ensemble des « formbean » (1 instance acceptée)
•
globalexceptions : l’ensemble des handler d’exception (1 instance acceptée)
•
globalforwards : l’ensemble des points de retour de type « global » (1 instance acceptée)
•
actionmappings : l’ensemble des mappings d’action (1 instance acceptée)
•
controller : paramétrage d’un contrôleur spécifique (dit RequestController) (1 instance acceptée)
•
messageresources : définition d’un bundle de messages (multiples instances acceptées)
•
plugin : définition d’un package (extérieur) connecté : plug’in (multiples instances acceptées)
3.8.2.Datasources
Vos objets modèles ont peut être besoin d’établir une connexion avec une base de données. Dans ce cas, vous pouvez utilisez Struts pour initialiser un pool de connexion plutôt que de passer directement par votre serveur d’application. L’intérêt premier est que vous n’aurez pas à « toucher » à la configuration de votre serveur d’application lors du déploiement de votre application. Cela simplifie donc grandement le déploiement de celleci.
Voici la partie de DTD correspondante aux DataSource :
<!ELEMENT datasources (datasource*)>
22 / 57
<!ATTLIST datasources id ID #IMPLIED>
<!ELEMENT datasource (setproperty*)>
<!ATTLIST datasource id ID #IMPLIED>
<!ATTLIST datasource className %ClassName; #IMPLIED>
<!ATTLIST datasource key %AttributeName; #IMPLIED>
<!ATTLIST datasource type %ClassName; #REQUIRED>
La balise datasources regroupe l’ensemble des datasource configuré pour l’application. Elle contient donc de 0 à n balises datasource.
Chaque balise datasource définit précisément les paramètres de configuration des connexions à une source de données (et plus précisément à des objets JDBC 2.0 DataSource). Voici les différentes balises qu’elle peut contenir : • className : cette balise est optionnelle. Elle définit la classe servant à configurer la source de données et doit donc contenir toutes les données nécessaires pour instancier une DataSource du type requis. Autrement dit, elle doit gérer l’ensemble des propriétés spécifiées dans les clauses setproperty (cf. plus bas) de la balise. Si cette balise est omise, Struts utilise la classe par défaut : org.apache.struts.config.Config pour gérer les propriétés.
• key : est une clé qui permet à l’application d’accéder à l’objet datasource créé par Struts. Par exemple dans le cas d’une clé : « stockdb », l’application pourra y accéder via : « org.apache.struts.action.DATA_SOURCE/stockdb » (si aucun préfixe de module n’existe : préfixe = "")
• type : spécifie le nom de la classe de la DataSource qui doit implémenter java.sql.DataSource. Cette classe est utilisée par Struts pour créer une instance de la datasource, elle configuré via la classe définit dans l’attribute « className ».
• setproperty : cette balise permet d’attribuer une clé et une valeur. Elles servent principalement à configurer les paramètres de connexion à la source de données (login, password, paramètres de la base…)
Voici la DTD correspondante : <!ELEMENT setproperty EMPTY>
<!ATTLIST setproperty id ID #IMPLIED>
<!ATTLIST setproperty property %PropName; #REQUIRED>
<!ATTLIST setproperty value CDATA #REQUIRED>
•
•
property : représente la clé (propriété)
value : représente la valeur liée à la clé
3.8.2.1.Exemple
Voici un exemple XML de la clause datasources : <datasource>
<setproperty property="autoCommit" value="true"/>
<setproperty property="decription" value="DataSource MysqlLocal"/>
<setproperty property="driverClass" value="com.mysql.jdbc.Driver"/>
<setproperty property="maxCount" value="4"/>
<setproperty property="minCount" value="1"/>
<setproperty property="user" value="root"/>
<setproperty property="password" value=""/>
23 / 57
<setproperty property="url" value="jdbc:mysql://localhost/contacts"/>
</datasource>
3.8.2.2.Utilisation dans l’application
Vous pouvez accéder à l’objet DataSource depuis une Action via le code suivant :
DataSource ds = servlet.getServletContext().getAttribute(“org.apache.struts.action.DATA_SOURCE/
stockdb”);
A partir de là, vous pourrez récupérer une connexion à votre source de données et effectuer tous les traitements que vous désirer.
3.8.3.FormBeans
Les balises formbeans et formbean indiquent à Struts à quel identifiant unique est associé une classe ActionForm. Elles servent également à initialiser les DynaForms (cf. §5.3).
Voici la partie de DTD correspondante :
<!ELEMENT formbeans (formbean*)>
<!ATTLIST formbeans id ID #IMPLIED>
<!ATTLIST formbeans type %ClassName; #IMPLIED>
<!ATTLIST formbean id ID #IMPLIED>
<!ATTLIST formbean className %ClassName; #IMPLIED>
<!ATTLIST formbean dynamic %Boolean; #IMPLIED>
<!ATTLIST formbean name %BeanName; #REQUIRED>
<!ATTLIST formbean type %ClassName; #REQUIRED>
<!ELEMENT formproperty (setproperty*)>
<!ATTLIST formproperty className %ClassName; #IMPLIED>
<!ATTLIST formproperty initial CDATA #IMPLIED>
<!ATTLIST formproperty name %PropName; #REQUIRED>
<!ATTLIST formproperty size %Integer; #IMPLIED>
<!ATTLIST formproperty type %ClassName; #REQUIRED>
Voici une description de chacune des balises : •
formbeans : encapsule la liste des beans formulaires définis. L’attribut type a été déclassé.
•
formbean : définit un formulaire unique. o
className : sert à définir un bean de configuration pour ce formulaire (comme pour les DataSource) cependant cela est n’est pas commun.
o
dynamic : a été déclassé
o
name : représente l’identifiant unique qui permet d’accéder au formulaire et d’associé ultérieurement le formulaire à une action. Remarque importante : si la portée de votre formulaire est celle de la session, vous pouvez accéder au formulaire via la méthode getAttribute() de l’objet session.
o
24 / 57
type : doit indiquer une classe ActionForm valide. C’est cette classe qui sera instanciée pour créer le formulaire.
Si le type dérive (ou est) : org.apache.struts.action.DynaActionForm, les balises formproperty sont également inspectées par Struts. Chacune d’elles définit une valeur initiale, un nom et un type (par exemple java.lang.String) pour chaque propriété du formulaire (cf. §5.3)
3.8.3.1.Exemple
<formbean name="contactForm"
type="com.society.contactbook.application.forms.ContactForm" />
3.8.4.Exceptions
La balise globalexceptions regroupe l’ensemble des exceptions que votre application gère au plus bas niveau durant le traitement d’une requête. Vous pouvez gérer autant de type d’exception que vous le souhaitez. Nous pouvons assimiler cette partie de configuration au try … catch dans le langage Java. En effet vous déclarez un bloc « catch » via une balise exception.
Voici une description des attributs qu’admet cette balise : •
bundle : spécifie le nom du bundle de ressources qui contiendra les messages pour cette exception.
•
handler : spécifie la classe appelée lorsque l’exception se produit. Elle doit impérativement dérivée de la classe org.apache.struts.action.ExceptionHandler ou d’une classe dérivée.
•
key : désigne la clé du message d’erreur qui sera généré et qui sera recherché dans le bundle de messages.
•
path : définit l’URL à laquelle le contrôle est transféré lorsque l’exception survient.
•
scope : indique à Struts s’il doit mémoriser les ActionError créées par la gestion de l’exception dans la portée de la session ou la requête.
•
type : nomme l’exception qui sera interceptée par ce gestionnaire.
3.8.4.1.Exemple
<globalexceptions>
<exception key=”database.error” path=”/errors/generalErrors.jsp”
scope=”request” type=”java.sql.SQLException” />
</globalexceptions>
Si une exception est lancée durant le traitement, le modèle database.error est recherché dans le bundle de ressources par défaut (ApplicationResources.properties), une nouvelle ActionError est créée à l’aide du modèle, puis elle est placée dans les attributs de la requête et le contrôle est transmis à la page d’erreur standard.
25 / 57
3.8.5.Global Forwards
Les transferts globaux servent à définir des chemins d’accès utilisables par toutes les actions définies dans la configuration. Si par exemple un certains nombre d’actions doivent transférer le contrôle à un écran de connexion, vous pouvez définir ce transfert ici au lieu de le faire dans chaque action.
Voici la partie de la DTD correspondante : <!ELEMENT globalforwards (forward*)>
<!ATTLIST globalforwards id ID #IMPLIED>
<!ATTLIST globalforwards type %ClassName; #IMPLIED>
<!ELEMENT forward (icon?, displayname?, description?, setproperty*)>
<!ATTLIST forward id ID #IMPLIED>
<!ATTLIST forward className %ClassName; #IMPLIED>
<!ATTLIST forward contextRelative %Boolean; #IMPLIED>
<!ATTLIST forward module %RequestPath; #IMPLIED>
<!ATTLIST forward name CDATA #REQUIRED>
<!ATTLIST forward path %RequestPath; #REQUIRED>
<!ATTLIST forward redirect %Boolean; #IMPLIED>
Voici la description de l’ensemble des attributs : •
contextRelative : indique si « path » est relatif au module d’une application modulaire (si faux) ou de l’application web (si vraie)
•
name : représente l’identifiant unique du forward. Il permet de retrouver ce forward dans une action avec la méthode findForward()
•
redirect : si positionné à true le contrôle est transmis à la page avec une redirection plutôt qu’un transfert. Une nouvelle requête est donc créée
Nous n’utilisons généralement pas les balises setproperty pour les forward. Cependant cellesci peuvent vous être utiles si vous souhaitez créer vos propres classes de forward (dérivant de la classe de base). Dans ce cas là vous devrez également indiquer le nom complet de la classe dans l’attribut : className.
3.8.5.1.Exemple
Voici un exemple simple d’utilisation de globalforwards : <globalforwards>
<forward name=”home” path=”/pages/home.jsp” />
</globalforwards>
3.8.6.Action mappings
Cette partie est sans doute la plus complexe. Elle relie les actions, les formulaires et les transferts. Voici la partie de la DTD correspondante : <!ELEMENT actionmappings (action*)>
<!ATTLIST actionmappings id ID #IMPLIED>
<!ATTLIST actionmappings type %ClassName; #IMPLIED>
26 / 57
<!ELEMENT action (icon?, displayname?, description?, setproperty*, exception*, forward*)>
<!ATTLIST action id ID #IMPLIED>
<!ATTLIST action attribute %BeanName; #IMPLIED>
<!ATTLIST action className %ClassName; #IMPLIED>
<!ATTLIST action forward %RequestPath; #IMPLIED>
<!ATTLIST action include %RequestPath; #IMPLIED>
<!ATTLIST action input %RequestPath; #IMPLIED>
<!ATTLIST action name %BeanName; #IMPLIED>
<!ATTLIST action parameter CDATA #IMPLIED>
<!ATTLIST action path %RequestPath; #REQUIRED>
<!ATTLIST action prefix CDATA #IMPLIED>
<!ATTLIST action roles CDATA #IMPLIED>
<!ATTLIST action scope %RequestScope; #IMPLIED>
<!ATTLIST action suffix CDATA #IMPLIED>
<!ATTLIST action type %ClassName; #IMPLIED>
<!ATTLIST action unknown %Boolean; #IMPLIED>
<!ATTLIST action validate %Boolean; #IMPLIED>
Voici une description de chacune des balises : • attribute : spécifie un ID unique permettant de mémoriser l’ActionForm dans la portée de la requête ou la session sinon name est utilisé
• forward / include : permettent de transférer le contrôle à un nouveau chemin au lieu de traiter l’action
• input : indique la page ou action qui a généré le formulaire servant à entrer les données
• parameter : permet de transmettre un autre paramètre à l’action, cependant il est alors préférable d’utiliser la balise plus générale : setproperty
• path : sert à relier la requête à l’action – ce doit être le chemin de l’action sans aucun suffixe. Si par exemple vous avez spécifié « /admin/add.do » dans l’action de votre formulaire alors vous indiquerez « /admin/add » dans le path
• prefix / suffixe : spécifient respectivement un préfixe et un suffixe qui seront ajoutés aux noms de propriétés du bean ActionForm avant de les associer aux noms de paramètre de la requête
• roles : permet de restreindre l’accès à l’action en indiquant un ensemble de rôle séparée par une virgule.
• type : spécifie la classe de l’Action.
• validate : si cette attribut est positionné à false, le contrôleur n’exécute pas la méthode validate() de l’ActionForm
3.8.6.1.Exemple
<action path="/Welcome"
scope="request"
validate=”false”
type="com.society.contactbook.application.actions.WelcomeAction">
<forward name="success" path="home" />
</action>
27 / 57
3.8.7.Controller
Cette balise n’est pas souvent utilisée. Seules les personnes souhaitant modifier le noyau de Struts s’en serviront !
<!ELEMENT controller (setproperty*)>
<!ATTLIST controller id ID #IMPLIED>
<!ATTLIST controller bufferSize %Integer; #IMPLIED>
<!ATTLIST controller className %ClassName; #IMPLIED>
<!ATTLIST controller contentType CDATA #IMPLIED>
<!ATTLIST controller forwardPattern CDATA #IMPLIED>
<!ATTLIST controller inputForward %Boolean; #IMPLIED>
<!ATTLIST controller locale %Boolean; #IMPLIED>
<!ATTLIST controller maxFileSize CDATA #IMPLIED>
<!ATTLIST controller memFileSize CDATA #IMPLIED>
<!ATTLIST controller multipartClass %ClassName; #IMPLIED>
<!ATTLIST controller nocache %Boolean; #IMPLIED>
<!ATTLIST controller pagePattern CDATA #IMPLIED>
<!ATTLIST controller processorClass %ClassName; #IMPLIED>
<!ATTLIST controller tempDir CDATA #IMPLIED>
Voici la description de chacun des attributs : •
bufferSize : permet de modifier la taille du tampon d’entrée lors du traitement de chargement de fichiers
•
maxFileSize : définit la taille maximale du fichier pouvant être chargé et peut être suivi d’un K (kilo), d’un M (méga) ou d’un G (giga)
•
contenType : permet de définir un autre type de contenu par défaut que « text/html »
•
debug : active le débuggage si la valeur est supérieure à 0
•
forwardPattern : permet de modifier la façon dont le chemin d’une application est lié à une URL relative au contexte à l’aide de forwardPattern. La valeur de $A est expansée en préfixe de l’application (/applicationContext par exemple) et celle de $P dans le chemin requis. Par défaut la valeur est $A$P
•
inputForward : positionné à true, les paramètres des attributs input des balises action sont traités comme des transferts et non comme des chemins. C'estàdire qu’ils sont comparés aux balises forward définies globalement et localement au lieur d’être traités comme des URI
•
locale : mémorise un locale dans la session de l’utilisateur si ce n’est pas déjà fait. (lorsque cet attribut est positionné à true)
•
nocache : une requête de désactivation de la mise en cache des contenus est envoyée au navigateur client avec chaque réponse HTTP
•
pagePattern : indique à Struts comment relier les pages à l’URL sousjacente, d’une façon assez semblable à forwardPattern
•
processorClass : remplace la classe « processor de requête » par défaut de Struts par une personnalisée.
28 / 57
3.8.7.1.Exemple
Voici un exemple de balise pouvant être utilisée : <controller nocache=”true” contentType=”image/jsp”/>
3.8.8.Messageresources
Cette balise vous permet de définir un bundle de ressources pour votre application. Vous pouvez, bien entendu, en définir plusieurs si besoin est.
<!ELEMENT messageresources (setproperty*)>
<!ATTLIST messageresources id ID #IMPLIED>
<!ATTLIST messageresources className %ClassName; #IMPLIED>
<!ATTLIST messageresources factory %ClassName; #IMPLIED>
<!ATTLIST messageresources key %AttributeName; #IMPLIED>
<!ATTLIST messageresources null %Boolean; #IMPLIED>
<!ATTLIST messageresources parameter CDATA #REQUIRED>
Voici une description de chacun des attributs :
•
factory : permet de spécifier d’où proviennent les données de la ressource de messages. Par défaut, il est configuré pour lire des fichiers « properties »
•
key : définit une clé pour accéder au bundle.
•
null : permet de spécifier ce qu’il faut faire lorsqu’un message n’est pas trouvé. Si l’attribut est positionné à true, il retourne null. Positionné à false, il retourne un message d’erreur avec la clé érronée.
•
parameter : permet de transmettre un paramètre à la fabrique lorsque le bundle est créé. Pour les fabriques à base de fichiers de propriétés, c’est le chemin du fichier.
3.8.8.1.Exemple
Voici un exemple de configuration d’un bundle :
<messageresources key=”com.labosun.MAIN_MESSAGES”
parameter=”com.labosun.MainMessages” />
Vous devez avoir un fichier MainMessages.properties dans votre package : com.labosun
3.8.9.Plugin
Ce dernier élément vous permet de charger dynamiquement des fonctionnalités supplémentaires dans le framework Struts.
<!ELEMENT plugin (setproperty*)>
<!ATTLIST plugin id ID #IMPLIED>
<!ATTLIST plugin className %ClassName; #REQUIRED>
Voici une description de chacun des attributs : http://www.labosun.com
29 / 57
•
className : spécifie la classe qui charge le plugin.
•
setproperty : permet de transférer au plugin les arguments nécessaires à son fonctionnement
3.8.9.1.Exemple
Voici un exemple de configuration du plugin « validator » :
<plugin className=”org.apache.struts.validator.ValidatorPlugIn”>
<setproperty property=”pathnames”
value=”/WEBINF/validatorrules.xml”,
”/WEBINF/validation.xml” />
</plugin>
3.9.Intégration avec l’application Web
Nous avons vu, jusqu’à présent, le fonctionnement de Struts indépendamment d’une application web basée sur un moteur de servlet. Si l’on ne peut pas intégrer Struts avec notre application web, alors ce framework est inutilisable ! Bien entendu une solution existe, nous allons rediriger un ensemble d’url (grâce au mapping par un pattern) à une servlet du framework Struts.
Nous utiliserons : org.apache.struts.action.ActionServlet. Cette servlet va nous permettre d’indiquer le fichier de configuration à utiliser, le type de debuggage à prendre en compte …
Nous n’avons plus, ensuite, qu’à mapping un type d’url à cette servlet. Voici un exemple de code à inclure dans le fichier de description de votre application web : web.xml :
<! Standard Action Servlet Configuration (with debugging) >
<servlet>
<servletname>actionstruts</servletname>
<servletclass>org.apache.struts.action.ActionServlet</servletclass>
<initparam>
<paramname>config</paramname>
<paramvalue>/WEBINF/strutsconfig.xml</paramvalue>
</initparam>
<initparam>
<paramname>debug</paramname>
<paramvalue>2</paramvalue>
</initparam>
<initparam>
<paramname>detail</paramname>
<paramvalue>2</paramvalue>
</initparam>
<loadonstartup>2</loadonstartup>
</servlet>
<! Standard Action Servlet Mapping >
<servletmapping>
<servletname>actionstruts</servletname>
<urlpattern>*.do</urlpattern>
</servletmapping>
30 / 57
31 / 57
4.Les tiles
4.1.Présentation
Lorsqu’on développe une application Web, on remarque généralement que l’ensemble des pages possède un élément central variable entouré d’éléments plus ou moins statiques (barre de navigation, entête, pied de page …)
La bibliothèque Tiles, qui est un plugin intégrable à Struts, permet de créer des modèles de page réutilisables pour l’ensemble de votre application à l’aide d’un document XML central.
Cette librairie peut s’utiliser aussi bien indépendamment de Struts ou en interne. Nous verrons ici l’utilisation intégrée à Struts (ce qui nous permet d’avoir toute la puissance de Struts combinée avec celle des tiles).
4.2.Architecture
Voici un schéma récapitulatif de l’architecture et utilisation de Tiles : Dfinitions (tilesdef.xml)
Struts configuration
strutsconfig.xml
mainLayout (1 dfinition)
Action mapping
index (extends mainLayout)
Action mapping
document (extends mainLayout)
body.jsp
(contenu)
header.jsp
(contenu)
layout1.jsp
(structure)
footer.jsp
(contenu)
32 / 57
Cette architecture préserve la séparation : structure des pages contenus des pages. En effet, vous pouvez créer autant de layouts que vous le souhaitiez ; pour affecter un layout à une page il suffit que la définition de cette page (dans le fichier de configuration) hérite du layout concerné. Nous pouvons donc remarquer que la couche application n’intervient pas directement sur les pages jsps mais passe par la couche de structuration (les tiles).
4.3.Installation
Afin de pouvoir utiliser la bibliothèque Tiles, vous devez la déclarer auprès de la configuration Struts.
Tiles étant un plugin struts vous avez juste à insérer ces quelques lignes dans votre fichier de configuration Struts : <plugin className="org.apache.struts.tiles.TilesPlugin">
<setproperty property="moduleAware" value="true" />
<setproperty property="definitionsparservalidate"
value="true" />
</plugin>
Tiles étant un plugin vous devez avoir les librairies dans votre classpath (tout comme vous avez les libraries de Struts dedans). Depuis la version 1.2 de Struts, Tiles est intégré dans Struts (struts.jar). Si vous utilisez une version antérieure (ce qui n’est pas recommandé) vous devrez ajouter la librairie Tiles manuellement (vous trouverez cette librairie ici : http:// …). Par défaut, le plugin initialise l’application avec le fichier : tilesdef.xml du dossier WEBINF.
4.4.Fichier de configuration
Le fichier de configuration, comme pour Struts, est le point central de gestion de Tiles dans votre application. C’est dans ce fichier que vous devrez définir l’ensemble des définitions de votre application. Voici une description de l’ensemble des balises pouvant êtres contenus dans ce fichier. Comme pour tout fichier xml bien formé, il suffit de se baser sur la DTD pour connaître l’ensemble de la structure à appliquer à notre fichier xml. Voici le lien vers la DTD du fichier de configuration des Tiles : http://jakarta.apache.org/struts/dtds/tilesconfig_1_1.dtd.
4.4.1.Balise racine
La première balise rencontrée est la balise « parente ». En effet, c’est elle qui va contenir l’ensemble des balises enfantes de configuration des Tiles.
<!ELEMENT tilesdefinitions (definition+)>
33 / 57
Cette balise ne peut contenir que des balises de type : definition. Elle ne sert qu’à regrouper l’ensemble des définitions.
4.4.2.Balise definition
C’est la balise la plus important. En effet, elle permet de définir une définition de tile, c’estàdire une structure de page pouvant être inséré dans une page ou directement utilisée en tant que forward dans la configuration Struts. Cette balise contient bien plus d’attribut que la précédente car elle permet de gérer l’ensemble des cas de structure d’une page (layout ou contenu de page). Voici la partie de DTD correspondante : <!ELEMENT definition (icon?, displayname?, description?, put*, putList*)>
<!ATTLIST definition id ID #IMPLIED>
<!ATTLIST definition controllerClass %ClassName; #IMPLIED>
<!ATTLIST definition controllerUrl %RequestPath; #IMPLIED>
<!ATTLIST definition extends %DefinitionName; #IMPLIED>
<!ATTLIST definition name %DefinitionName; #REQUIRED>
<!ATTLIST definition page %RequestPath; #IMPLIED>
<!ATTLIST definition path %RequestPath; #IMPLIED>
<!ATTLIST definition role CDATA #IMPLIED>
<!ATTLIST definition template %RequestPath; #IMPLIED>
•
•
•
•
•
•
controllerClass : le nom complet de la classe spécifique à utiliser en tant que contrôleur (si on ne souhaite pas utiliser celle par défaut)
extends : utiliser pour faire dériver la définition en cours d’une définition mère (cela permet de surdéfinir les valeurs des attributs de la définition mère)
name : nom unique de la définition
path (ou page) : définit la page à utiliser pour la structure de cette tile (layout). La ressource est alors chargée (ou incluse en cas de page jsp)
role : définit un role pour la gestion de la sécurité (définition du type d’acc§s à la définition)
template : même chose que path. Utilisé pour la compatibilité avec la librairie : Template
Une définition peut également contenir des balises put et putList qui permette de définir des attributs (put) et des listes (putList).
4.4.3.Balise put
La balise put permet de définir un attribut (clé => valeur) dans une définition. Voici la DTD correspondate : <!ELEMENT put (#PCDATA)>
<!ATTLIST put id ID #IMPLIED>
<!ATTLIST put content CDATA #IMPLIED>
<!ATTLIST put direct %Boolean; #IMPLIED>
34 / 57
<!ATTLIST put name CDATA #REQUIRED>
<!ATTLIST put type %ContentType; #IMPLIED>
<!ATTLIST put value CDATA #IMPLIED>
•
•
•
•
•
name : l’identifiant unique pour l’attribut (la clé)
type : définit le type de la valeur (string, page, template, definition)
direct : même chose que : type="string" (compatibilité avec Template)
value (ou content) : la valeur associé à la clé (définit avec l’attribut name)
content : même chose que value (compatiblité avec Template)
4.4.4.Balise putList
La balise putList permet de définir une liste dans une définition.
Voici la DTD correspondante : <!ELEMENT putList ( (add* | item* | bean* | putList*)+) >
<!ATTLIST putList id ID #IMPLIED>
<!ATTLIST putList name CDATA #REQUIRED>
Le seul attribut est le nom de la liste (name). Cependant la liste peut contenir différents éléments : •
•
•
•
add : même chose qu’un élément put
item : élément spécifique de la liste (cf. cidessous)
bean : élément de type JavaBean (cf. cidessous)
putList : autre liste
4.4.5.Balise item
La balise item est utilisée pour définir un élément dans une liste. Cet élément peut contenir différentes propriétés (valeur, icône, lien, message d’information).
Voici la partie DTD correspondante : <!ELEMENT item (#PCDATA)>
<!ATTLIST item id ID #IMPLIED>
<!ATTLIST item classtype %ClassName; #IMPLIED>
<!ATTLIST item icon CDATA #IMPLIED>
<!ATTLIST item link CDATA #REQUIRED>
<!ATTLIST item tooltip CDATA #IMPLIED>
<!ATTLIST item value CDATA #REQUIRED>
•
•
•
•
•
35 / 57
classtype : nom complet de la classe à utiliser (par défaut : org.apache.struts.tiles.beans.MenuItem)
icon : valeur de la propriété icon
link : valeur de la propriété link
tooltip : valeur de la propriété tooltip
value : valeur de la propriété value
4.4.6.Balise bean
La balise bean permet de définir un élément de type : JavaBean dans une liste. Cela permet de personnalité l’ensemble des propriétés disponibles. Chacune de ses propriétés étant initialisée via une balise : setproperty (description cidessous).
Voici la partie de DTD correspondante :
<!ELEMENT bean (setproperty*)>
<!ATTLIST bean id ID #IMPLIED>
<!ATTLIST bean classtype %ClassName; #REQUIRED>
Vous pouvez remarquer que l’attribut principal est : classtype qui permet de définir le nom complet de la classe à utiliser pour le JavaBean.
4.4.7.Balise setproperty
La balise setproperty se retrouve très souvent dans les fichiers de configuration (cf. balise Datasource fichier de configuration Struts). Elle permet d’initialiser une propriété d’un Bean en indiquant le nom de celleci et la valeur associée.
Voici la DTD correspondante : <!ELEMENT setproperty EMPTY>
<!ATTLIST setproperty id ID #IMPLIED>
<!ATTLIST setproperty property %PropName; #REQUIRED>
<!ATTLIST setproperty value CDATA #REQUIRED>
•
property : désigne le nom de propriété à initialiser
•
value : désigne la valeur à associer à la propriété
Voici la majorité des balises / attributs utilisés dans le développement avec le plugin Tiles. Vous pouvez remarquer qu’il n’y a aucun moyen de différencier vos templates (ou layout) de vos pages réellement utilisables. En effet Tiles vous fournit le simple fait de créer des définitions et de faire de l’héritage entre elles. C’est donc au développeur de gérer (via une norme, convention …) la différenciation entre layout et pages.
36 / 57
4.5.Layouts
Les layout définissent (un peu comme dans la librairie SWING) la structure d’une page, c’est à dire les différents éléments d’un modèle et le positionnement de ceuxlà.
Vous pouvez créer des modèles pour : •
les pages
•
des composants (liste, formulaire …)
•
des vues spéciales
•
…
En théorie, vous n’utiliserez jamais directement une définition « type layout » dans une page jsp (sauf cas spécifiques) mais vous les utiliserez comme définitions parentes.
Voici un exemple de définition qui représente un modèle de page : <definition name="template.main" path="/tileslayouts/mainTemplate.jsp" > <put name="title" value="No title" />
<put name="header" value="/tilescomponents/default/header.jsp" />
<put name="hmenu" value="pub.hmenu.default" />
<put name="vmenu" value="pub.vmenu.default" />
<put name="cbody" value="/tilescomponents/default/cbody.jsp" />
<put name="rbody" value="/tilescomponents/default/rbody.jsp" />
<put name="footer" value="/tilescomponents/default/footer.jsp" />
</definition>
Cette définition déclare un « modèle » de page qui contient : • un titre : title
• un bandeau entête : header
• un menu horizontal : hmenu
• un menu vertical : vmenu
• un contenu principale : cbody
• un contenu secondaire : rbody
• un pied de page : footer
Une page jsp de structure est associée à cette définition (via path="") afin qu’on puisse définir le positionnement de chacun des éléments. Dans cette définition les éléments sont déclarés et initialisés par des valeurs « par défaut ».
Cette définition a été écrite afin d’être utilisé par des définitions de page réelle.
4.5.1.Le fichier de structure
Nous venons de voir comment déclarer une définition, cependant dans le cas d’un modèle (layout) nous devons utiliser une page JSP afin d’indiquer comment placer les éléments.
37 / 57
Dans votre page JSP, vous pouvez alors utiliser les valeurs de chacun des attributs pour les insérer dans votre page modèle.
Votre attribut peut pointer vers différente chose : •
Une chaîne de caractère •
Une définition
•
Une page JSP ou autre
Il vous faudra utiliser la librairie tiles (taglib) dans votre page modèle afin d’insérer les différents éléments. Voici une description de l’ensemble de cette librairie :
// TODO
// TABLEAU
Voici un exemple de page modele de base : <%@ taglib uri="/tags/strutstiles" prefix="tiles" %>
<html>
<title><tiles:getAsString name="title" /></title>
<body>
<table width="100%" height="100%" >
<tr height="100" align="center" bgcolor="#001188" ><td>
<tiles:insert attribute="header" />
</td></tr>
<tr bgcolor="#FFFFFF" ><td valign="top" >
<TABLE>
<tr>
<td width="250" valign="top" >
<tiles:insert attribute="menu" />
<td>
<td>
<tiles:insert attribute="body" />
</td>
</tr>
</TABLE>
</td></tr>
<tr height="100" align="center" bgcolor="#001166" ><td>
<tiles:insert attribute="footer" />
</td></tr>
</table>
</body>
</html>
38 / 57
Ce fichier permet de définir l’emplacement des composants. Chaque définition de page qui héritera du layout utilisant cette page verra ses composants placés de cette manière : Header
M
E
N
U
Body
Footer
4.6.Tiles
Les Tiles sont également des définitions. Cependant elles sont utilisables réellement car elle définissent des pages « finales ». Une tile est le plus souvent une définition héritant d’une autre (de type layout) et qui surdéfinit l’ensemble des attributs spécifique à la tile. Par exemple, si vous utilisez le modèle décrit précédemment vous pouvez juste avoir besoin de redéfinir le titre de la page et le contenu principale (voir également secondaire). Dans ce cas là, vous gardez le bandeau, les menus, le footer par défauts.
Cela évite la redondance d’information et si vous souhaitez changer de bandeau, il vous suffira de modifier la définition du modèle principal.
4.7.Exemple d’architecture de définitions
Voici un schéma récapitulatif d’une utilisation de la librairie Tiles : http://www.labosun.com
Layouts
Page
pub.login
Dfinition relles
pub.index
Form
form.user
form.login
39 / 57
List
list.ress
list.users
pub.ress
Nous avons donc 3 layouts : •
Page : structure globale d’une page
•
Form : modèle pour les formulaires •
List : modèle pour les listes
Ensuite les définitions (tiles) héritent du layout à utiliser et redéfinissent les éléments à personnaliser.
40 / 57
5.Validator & Formulaires
5.1.Présentation et architecture
Struts permet de créer facilement des formulaires à l’aide de différentes balises personnalisées. La question maintenant est : comment gérer la validation de ces formulaires ?
Pour cela, il existe le framework Validator (inclus dans le Projet Commons d’Apache), développé par David Winterfeldt. Il était au départ une tierce partie ajoutée au framework Struts. Aujourd’hui, c’est un framework indépendant pouvant être utilisé avec ou sans Struts.
Ce framework contient différents outils qui vont nous éviter de devoir réécrire nos propres classes de validation. Ainsi, pour vérifier que des champs sont bien remplis ou bien dans un certain format, on a un gain de temps non négligeable.
Le principe est le suivant : Dans la liste des fichiers de configuration de Struts, que vous trouverez dans le répertoire ~/WEBINF/, se trouvent les fichiers validation.xml et validatorrules.xml qui vont permettre entre autres le mapping entre les balises des formulaires et les classes de validations.
Dans le répertoire ~/WEBINF/lib, se trouvent 2 fichiers jar, commonsvalidator.jar et jakartaoro.jar qui contiennent ces classes de validations.
Chaque fois que l’on souhaite faire une vérification sur un champ d’un formulaire, on va mapper ce champ à la méthode de la classe correspondante. Cela peut paraître flou au départ, mais nous verrons dans les chapitres suivants, la marche à suivre qui est en fait très simple.
5.2.Fichiers de configuration
5.2.1.Dans le fichier strutsconfig.xml
Ce framework de validation nécessite donc l’utilisation de deux fichiers de configuration que l’on va « déclarer », tels des plugins, dans le fichier strutsconfig.xml. Pour cela on va utiliser la balise <plugin> et lui indiquer les chemins vers nos deux fichiers XML:
Définition de la balise <plugin> :
plugin
Élément racine de la définition. On a une balise plugin pour chaque http://www.labosun.com
41 / 57
"plugin" ajouté.
className : attribut de la balise plugin, il permet de définir le chemin de la classe à instancier,interne ou externe à Struts. Cela signifie que l’on peut parfaitement créer son propre framework de validation voire un framework d’une toute autre utilité.
o
setproperty
Si la classe instanciée (className) prend des arguments en paramètre, ils seront définis dans cette balise. On a donc une balise setproperty pour chacun des arguments.
property : attribut de la balise setproperty, il permet de spécifier le nom de l’argument.
values : attribut de la balise setproperty, il permet de spécifier la valeur de l’argument défini dans property.
Nous venons donc de spécifier une nouvelle balise plugin, tout comme on l’a fait pour les Tiles précédemment, et deux nouveaux fichiers. Voyons donc plus en détail ce que sont ces fichiers et à quoi ils vont nous servir.
5.2.2.Le fichier validatorrules.xml : Fourni avec le plugin, ce fichier XML défini les règles que l’on pourra utiliser pour tester les valeurs des champs. Il permet d’effectuer le lien entre le type de validation (champ requis, champ email …) et le chemin vers la méthode et la classe correspondante qui permettront d’effectuer l’opération de vérification des données (valeur du champs). De base, Struts Validator gère les champs vides, les formats d’email ou de date invalides, les longueurs de champs minimum ou maximum, et bien d’autres encore. Vous trouverez la description de toutes ces validations sur le site de la fondation Apache : http://struts.apache.org/userGuide/dev_validator.html dans la section "Standard Built In Validations".
Définition des balises du fichier validatorrules.xml :
formvalidation
o
global

Élément racine du fichier.
Tous les éléments inclus dans la balise global seront accessibles par l’ensemble des formulaires (sorte de constantes)
validator
Définit chaque type de validation et le lie la méthode correspondante.
Attributs de la balise validator : name : définit le nom logique de la validation.
classname : définit le chemin vers la classe contenant la méthode de validation correspondante.
42 / 57
method : définit le nom de la méthode de validation correspondante.
methodParams : type des arguments passés en paramètre. msg : définit le message d’erreur à afficher en cas de non validation du champ.
depends : définit si la validation est obligatoire ou non.
jsFunctionName : définit le nom de la fonction javascript correspondante qui s’executera côté client

javascript
Définit le code de la fonction javascript qui s’exécutera côté client.
Nous allons voir une explication de l’un des "validator" fourni par défaut dans le fichier validator
rules de base.
Il s’agit ici du validator vérifiant qu’un champ est requis, c’estàdire qu’il vérifie que le champ n’est pas vide. On peut donc voir qu’il a été nommé "required", qu’il est rattaché à la méthode validateRequired de la classe FieldChecks. En cas de « non validation » du champ mappé à ce validator, le message d’erreur se trouvant un peu plus haut dans le fichier validatorrules.xml sera affiché :
Dans le cas présent, on aurait le message arg0 is required.
5.2.3.Le fichier validation.xml : Une fois les différents types de validation définis, c’est dans le fichier validation.xml qui va nous servir a mapper les champs de nos formulaires aux validations définies dans validatorrules.xml.
Définition des balises du fichier validation.xml :
formvalidation
o
global
Élément racine du fichier.
Entre ces balises vont être définies des informations qui seront accessibles, visibles par l’ensemble des formulaires de notre fichier (constantes).
constant
A chaque constante correspond une balise constant.
•
constantname
Cette balise permet de définir le nom de la constante
•
constantvalue
Cette balise permet de définir la valeur de la constante. On va pouvoir par exemple définir l’expression régulière définissant la valeur de cette constante

o
Cette balise va englober tous les mappings de nos différents formulaires.
formset

43 / 57
form
À chaque formulaire correspond une balise form.
name : attribut de la balise form, il permet de définir le nom du formulaire concerné. Ce nom correspond à celui défini dans le fichier strutsconfig.xml (attribut name de la balise formbean).
•
field
À chaque champ du formulaire nécessitant une validation correspond une balise field.
property : attribut de la balise field, c’est ici que l’on va spécifier le nom de la propriété (champ) que l’on va lier à la ou les validations définie(s) dans validatorrules.xml. Ce nom de propriété est celui défini dans le Form Bean.
depends : attribut de la balise field, il permet de spécifier les noms des validations associées au champ property.

argn : balise interne à la balise field, elle permet de spécifier l’argument à donner au message d’erreur correspondant.

var : balise interne de la balise field, elle va permettre de préciser(si besoin est) une contrainte d’intégrité pour les validations spécifiées dans l’attribut depends. o
varname : balise interne de la balise var, on va spécifier le nom de la validation dont on veut donner la contrainte d’intégrité. o
varvalue : balise interne de la balise var, on va spécifier la contrainte d’intégrité (exemple : expression régulière,...). http://www.labosun.com
44 / 57
Jusqu’à maintenant nous avons un fichier validatorrules.xml qui définit une liste de validations dont les classes (et donc méthodes) se trouvent dans les fichiers commonsvalidator.jar et jakarta
oro.jar.
On a par ailleurs un formulaire d’inscription(InscripForm) avec les champs nom(obligatoire), password(obligatoire, taille minimum de 4 caractères) et email(obligatoire, format d’email).
Nous souhaitons donc vérifier la validité de ces champs. Ceci va être fait dans le fichier validation.xml. C’est en effet ici que l’on va lier chacun de nos champs aux types de validations déclarées dans validatorrules.xml. D’après les règles de la validation définies cidessus pour le formulaire InscripForm, on peut voir que l’on va utiliser les validators suivants (présents dans le fichier validatorrules.xml de base) : required, email et minlength.
Voici donc comment se présentera notre fichier validation.xml pour la partie concernant InscripForm :
Voyons l’explication du fichier ligne par ligne : o
Toutes nos définitions sont englobées dans la balise racine formvalidation.
Dans un premier temps, nous définissons une constante minPass. Elle définit la longueur minimum du mot de passe. On l’englobe dans une balise <global>, ce qui signifie qu’elle sera visible par toutes les définitions de formulaire qui vont suivre. Nous avons besoin du champ password dans le formulaire InscripForm, et étant susceptible d’être réutilisé dans un autre formulaire, on a choisi de déclarer cette constante minPass avec http://www.labosun.com
45 / 57
une portée globale. Sachant que le champ password devra avoir une longueur supérieure à 4, la valeur de minPass est initialisée à 4.
o
La balise <formset> contient l’ensemble des validations des différents formulaires. Cela signifie que l’on aura une balise <form> pour chaque définition de formulaire. Dans notre cas, nous n’avons que InscripForm, nous avons donc une seule balise <form>.
Nous ouvrons donc la balise <form> et indiquons dans l’attribut name, l’identifiant de notre formulaire indiqué dans le fichier strutsconfig.xml, "inscripForm".
Le premier champ dont nous devons vérifier la validité est le champ nom, il est en effet obligatoire. L’objet que nous allons créer ici est un objet client. Dans la balise <field> est donc indiqué le nom de la propriété concernée, c’estàdire nom. Étant un champ obligatoire, on ajoute le validator required(cf :valitorrules.xml) pour l’attribut depends. On vient donc de lier le champ nom du formulaire au validator required.
En cas d’erreur de validation, le message arg0 is required sera affiché (chapitre sur validator
rules.xml ). Afin de spécifier justement le nom qui sera affiché pour arg0, on utilise la balise <argn> avec 0 pour la valeur de n. La valeur de arg0 est défini dans l’attribut key, il s’agit de la valeur de client.form.require.nom du fichier de properties.
On vient maintenant de définir plus précisément le message d’erreur.
o
Nous allons agir de la même manière que pour le champ nom avec le champ password. Ce champ est obligatoire et doit être d’une longueur minimum de 4 caractères. L’attribut depends a donc pour valeurs required et minlength.
Afin de spécifier la valeur de minlength, on utilise la balise <var>. <varname> nous permet de spécifier le nom du validator concerné et <varvalue>, la valeur, justement que l’on va affecter à ce validator.
Précédemment, nous avons spécifier que la constante minPass a été initialisée en début de fichier, avec une portée globale. Nous réutilisons donc cette constante afin de l’affecter à minlength.
o
46 / 57
Les validators pour les champs nom et password viennent donc d’être définis. Il ne reste que le champ email dont la démarche est la même. Simplement les validators concernés sont required et email (toujours du fichier validatorrules.xml).
Nous venons donc de :

initialiser le plugin Validator dans le fichier strutsconfig.xml et fait les liens avec les fichiers validation.xml et validatorrules.xml.

définir les différentes validations dans le fichier validatorrules.xml en faisant les liens avec les classes concernées.

définir les validations à faire sur les champs de notre formulaire en faisant les liens entre ces champs et les validators (définis dans validatorrules.xml), dans le fichier validation.xml.
Cependant, nous n’avons pas parlé des Form beans ; en effet, la classe associée à notre formulaire InscripForm doit étendre la classe DynaActionForm, classe fille de la classe ActionForm.
5.3.DynaForms
On a vu jusque maintenant comment lier les champs de nos formulaires, mais à aucun moment la définition de la classe Form Bean correspondante.
En effet, si l’on utilise Struts, il faut nécessairement lier chaque formulaire à un bean ; c’estàdire à une classe Java respectant certaines règles :

un attribut pour chaque propriété du formulaire avec le même nom

un getter et un setter pour chaque attribut du bean
Par ailleurs cette classe doit étendre ActionForm. La classe ActionForm possède en effet une méthode validate() qui va justement permettre de définir le code validant ou non les champs du formulaire.
Si l’on suit cette indication, notre classe InscripForm est définie comme suit : http://www.labosun.com
47 / 57
Cette classe contient des attributs correspondants aux propriétés de notre formulaire InscripForm ainsi que des getters et des setters pour chacun d’eux. Elle surdéfinit par ailleurs la méthode validate() de la classe ActionForm afin de faire les validations des différents champs du formulaire.
Rappelons que client.form.require.nom fait référence à la clé se trouvant dans le fichier de properties(cf.3.6.1) qu’on aura défini en amont. Le lien avec ce fichier se fait dans le fichier de configuration strutsconfig.xml à l’aide de la balise <messageresources> (cf.3.8.1).
Après avoir créé notre Form Bean, revoyons le fichier strutsconfig.xml : http://www.labosun.com
48 / 57
Le fait est que, si nous avons choisi d’utiliser le framework Validator, c’est justement dans le but d’éviter d’écrire les codes de validations pour chaque formulaire puisqu’ils risquent d’être redondants. C’est pourquoi un ensemble de validations standards sont regroupés dans le fichier struts.jar. De plus, c’est pour cela que nous avons regroupé toutes les définitions des validations de champs dans le fichier validation.xml.
Ce que l’on veut, c’est se servir de ces définitions et les mapper à notre Form Bean.
Nous allons donc étendre la classe ValidatorForm, sousclasse de la classe ActionForm. Cette classe est incluse dans le framework Validator (on pourra le trouver dans le fichier struts.jar, dans le package org.apache.struts.validator).Voyons la nouvelle classe InscripForm :
Sa définition dans le fichier strutsconfig.xml ne change pas : Simplement, les validations des champs vont se faire par rapport au fichier validation.xml. Le nom défini dans l’attribut name est l’identifiant qui permettra, de lier les champs du formulaire InscripForm aux validators requis.
Nous avons déjà gagné un temps non négligeable, puisque pour chaque formulaire, il nous suffit de créer un Form Bean contenant des attributs ainsi que leurs accesseurs. Mais nous allons encore simplifier la chose. En effet, chaque fois redéfinir toutes ces méthodes pour chaque champ est assez fastidieux.
49 / 57
Pour cela, nous n’allons plus créer de Form Bean pour chaque formulaire mais utiliser les DynaForms, c’estàdire définir nos balises <form bean>de la manière suivante : Avec cette nouvelle définition, Struts va s’occuper luimême de créer le Form Bean. Nous ne devons que spécifier les propriétés du formulaire ainsi que leurs types.
On a donc deux propriétés à valider pour ce formulaire inscripForm, de types String et initialisées à vide. 5.4.Résumé de la configuration des Validators Résumons les différentes étapes à réaliser pour gérer la validation d’un formulaire : 1. Instancier la classe ValidatorPlugin à l’aide de la balise <plugin> afin de donner l’accès aux fonctionnalités du framework Validator à Struts.
2. Configurer les deux fichiers de configuration validatorrules.xml(dont la configuration par défaut et amplement suffisante) et validation.xml.
3. Créer un Form Bean qui étend la classe ActionForm.
Il est donc assez rapide de gérer la validation des formulaires à l’aide du framework Validator.
50 / 57
6.Intégration avec XDoclet
xDoclet est un outil très intéressant pour la génération automatique de code ou descripteurs de déploiement ou autres fichiers utiles.
Nous allons étudier, dans cette partie, l’intégration de XDoclet pour la génération des fichiers de configuration struts (strutsconfig.xml, validation.xml …). Afin de bien comprendre le principe XDoclet, il faut savoir l’utiliser et connaître Ant (cf. Essentiel Ant).
6.1.Strutsconfig.xml
La génération du fichier strutsconfig.xml est automatisable avec XDoclet.
Grâce à XDoclet vous allez pouvoir définir directement dans votre code java : •
Les actionmapping •
Les actionexception •
Les actionforward
•
Les actionform
•
Les actiondynaform
Ces définitions vont se faire à partir des tags XDoclet « @Struts » que vous pouvez retrouver à l’adresse : http://xdoclet.sourceforge.net/xdoclet/tags/apachetags.html
Nous allons détailler les plus importants dans cette section.
6.1.1.Tags @Struts
Voici une description non exhaustive des tags les plus utilisés avec Struts : •
@struts.action : définit un mapping pour une classe d’action et les différents attributs liés
o
name : nom de l’action (doit être unique dans l’ensemble de l’application struts)
o
type : type de la classe à utiliser (par défaut, la classe en cours). Il est possible de surcharger cette valeur dans certains cas (par exemple avec l’utilisation de framework externe tel que Spring)
o
path : chemin de l’action (url)
o
scope : domaine dans lequel l’action va exister (request, session, application ; request par défaut)
o
input : chemin d’input pour l’action
•
•
•
51 / 57
o
roles : rôle(s) autorisé(s) à accéder à cette action
o
validate : indique si struts doit valider les entrés du formulaire (true | false, true par défaut)
o
parameter : paramètre d’option de l’action (il faut mettre « action »).
struts.actionexception : définit un handler sur un type d’exception (liée à l’action)
o
key : clé de la propriété à utiliser pour retrouver le texte de l’erreur
o
type : nom absolu de la classe d’exception qui sera intercepté
o
handler : nom absolu de la classe à utiliser comme Handler de l’exception
o
path : chemin vers la ressource qui permettra de terminer la requête
o
scope : domaine dans lequel l’objet ActionError sera utilisé.
struts.actionforward : définit un « forward » local pour l’action
o
name : nom du forward qui sera utilisé dans l’action
o
path : chemin vers la ressource à utiliser
o
redirect : indique s’il faut effectuer une redirection ou non (true | false, false par défaut)
strutsform : définit un « form bean » et ses attributs
o
name : nom du « form bean » qui permettra de le référencer
On retrouve également les tags liés au plugin Validator : •
struts.validator : définit la validation à effectuer sur un champ du formulaire
o
•
•
type : définit le type de validation à effectuer sur le champ (« required » par exemple)
struts.validatorargs : définit un argument à appliquer à la validation
o
arg0value
o
arg1value
o
arg2value
o
arg3value
struts.validatorvar : déclare une variable pour le validator
o
name : nom de la variable
o
value : valeur de la variable
D’autres attributs peuvent être utilisés dans certains cas. Nous ne les avons pas détaillé afin de simplifier cette présentation.
6.1.2.Exemples
Voici quelques exemples d’utilisation de ces tags dans le code java. Exemple de class Action : /**
* * @struts.action path="/admin/comment/add/display" name="commentForm"
* scope="request" validate="false" parameter="action"
* * @struts.actionforward name="success" path="admin.comment.add.display"
*/
public class DisplayCommentFormAction extends Action {
protected ActionForward delegateExecute(ActionMapping mappings,
ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws ApplicationException {
....
return mappings.findForward("success");
}
}
Utilisation avec les ActionForm :
/**
* LoginForm class.
* * @struts.form name="loginForm"
*/
public class LoginForm extends BaseForm {
// Membres
private String loginTxt;
private String password;
/**
* Default constructor.
* */
public LoginForm() {
}
/**
* @return Returns the login.
52 / 57
* @struts.validator type="required"
* @struts.validatorargs arg0value="key.form.login.required.login"
*/
public String getLoginTxt() {
return loginTxt;
}
/**
* @param login
* The login to set.
*/
public void setLoginTxt(String login) {
this.loginTxt = login;
}
/**
* @return Returns the password.
* @struts.validator type="required"
* @struts.validatorargs arg0value="key.form.login.required.password"
*/
public String getPassword() {
return password;
}
/**
* @param password
* The password to set.
*/
public void setPassword(String password) {
this.password = password;
}
}
6.1.3.Intégration avec Ant
XDoclet s’intègre avec Ant afin de pouvoir automatiser son exécution au sein d’un script. <target name="appwebdoclet" depends="appcompile">
<taskdef name="webdoclet" classname="xdoclet.modules.web.WebDocletTask">
<classpath>
<path refid="xdoclet.classpath" />
<path refid="web.compile.classpath" />
</classpath>
</taskdef>
<! xDoclet pour le web (struts et web.xml) >
<webdoclet force="${xdoclet.force}" destdir="${web.gen.target.dir}" mergedir="${web.merge.dir}" excludedtags="@version,@author" verbose="true">
<fileset dir="${struts.source.dir}">
<include name="**/*.java" />
</fileset>
53 / 57
54 / 57
<! strutsconfig.xml >
<strutsconfigxml validateXML="true" version="1.2">
</strutsconfigxml>
</webdoclet>
</target>
Il faut : •
Déclarer la tâche « webdoclet » via « taskdef », en lui spécifiant la classe : xdoclet.modules.web.WebDocletTask à utiliser. Vous devez donc spécifier un classpath valide contenant la classe précédente (incluse dans les jars XDoclet).
•
Appeler la tâche webdoclet en lui spécifiant le répertoire de destination (destdir), les fichiers à parser (via un fileset), et la soustâche « strutsconfigxml » qui permet de générer le fichier strutsconfig.xml.
Vous pouvez également utiliser les sous tâches suivantes : •
strutsdynaformvalidationxml : pour la génération des paramétrages de vos « dynaform ».
•
strutsvalidationxml : pour la génération du fichier validation.xml
Vous pouvez avoir plus de détails sur l’utilisation de chacune de ces tâches à l’adresse suivante : http://xdoclet.sourceforge.net/xdoclet/ant/xdoclet/modules/web/WebDocletTask.html.
55 / 57
7.Cas concret (architecture)
7.1.Présentation
Nous allons à présent prendre un cas concret d’application et voir les différentes étapes au niveau de la modélisation de l’application. Nous allons prendre l’exemple d’une gestion d’un portefeuille d’actions
Cas d’utilisation ???? 7.2.Architecture
7.3.Couche métier
7.3.1.Couche d’accès aux données (DAO)
7.3.2.Couche service
7.4.Couche application
7.4.1.Action
7.4.1.1.ActionForm
7.4.2.Forwards
7.4.3.Exceptions
7.5.Couche présentation
7.5.1.Tiles
7.5.1.1.Définitions
7.5.1.2.Jsp (layouts et tiles)
7.5.2.Formulaires
7.5.3.Messages d’erreur (MessageApplication)
56 / 57
57 / 57
8.L’avenir de Struts
8.1.Intégration avec JSTL
En adoptant JSP 1.2, les différents serveurs d’applications peuvent exploiter toute l’efficacité de JSTL (Java Standard Tag Library). Le principal effet sur Struts sera de fournir une solution de rechange à la bibliothèque de balises de Struts beaucoup plus puissante et capable d’interopérabilité avec les platesformes non Struts.
En conséquence, on peut s’attendre progressivement à une dévalorisation des balises Struts.
8.2.Intégration avec JSF
L’auteur de Struts : Craig McClanahan est fortement impliqué dans les spécifications des JSF (Java Server Faces). Struts et JSF seront donc probablement bientôt étroitement liés.
Une fois de plus l’intérêt pour les balises Struts s’estompera pour celle de JSF (toujours dans le but d’avoir un standard).
8.3.Adoption généralisée de Struts
Struts est devenu rapidement très populaire dans la communauté de développement Java J2EE. IBM, Oracle sont de bons exemples de leader ayant choisit Struts dans leur outil de développement d’application Web.
Fin du document