3. Traitement du formulaire par le contrôleur
Nous nous intéressons maintenant au traitement des valeurs du formulaire par le contrôleur lorsque l'utilisateur va appuyer sur le bouton [Envoyer] du formulaire.
3.1. Le fichier struts-config.xml
Le nouveau fichier de configuration struts-config.xml du contrôleur Struts devient le suivant :
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">
<struts-config>
<form-beans>
<form-bean
name="frmPersonne"
type="istia.st.struts.personne.FormulaireBean"
/>
</form-beans>
<action-mappings>
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
<action
path="/reponse"
parameter="/vues/reponse.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
</action-mappings>
<message-resources parameter="ressources.personneressources"/>
</struts-config>
Nous avons mis en relief les changements :
- une section <form-beans> apparaît. Elle sert à définir les classes associées à chacun des formulaire de l'application. Il doit y avoir autant de balises <form-bean> que de formulaires différents dans l'application. Ici, nous n'avons qu'un formulaire donc une seule section <form-bean>. Pour chaque formulaire, nous devons définir :
- son nom (attribut name)
- le nom de la classe dérivée de ActionForm chargée de stocker les valeurs du formulaire (attribut type)
Ces deux attributs ne peuvent être quelconques. Ils doivent être identiques à ceux utilisés dans la balise <html:form> du code HTML du formulaire. Rappelons celle-ci pour le formulaire (nom, age) :
Le formulaire doit être déclaré de la même façon dans le fichier struts-config.html. C'est ce qui est fait ici :
- la configuration de l'action /main a changé. Celle-ci est chargée de traiter les valeurs du formulaire. Aussi doit-on donner les informations dont elle a besoin sur celui-ci :
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
La servlet /main va traiter un formulaire dont il faut lui donner le nom. C'est l'attribut name qui fait ce travail. Ce nom doit référencer l'attribut name de l'une des sections <form-bean>, ici frmPersonne.
L'attribut scope="session" indique que les valeurs du formulaire doivent être stockées dans la session. Ce n'est pas toujours nécessaire. Ici, ça l'est. En effet, nous trouvons dans les vues /reponse.do et /erreurs.do des liens ramenant au formulaire. Dans les deux cas, nous voulons afficher le formulaire avec les valeurs saisies par l'utilisateur lors d'un précédent échange client-serveur. D'où la nécessité de stocker le formulaire dans la session.
L'attribut validate indique si la méthode validate de l'objet frmPersonne doit être appelée ou non. Cette méthode sert à vérifier la validité des données du formulaire. Ici, nous indiquons que les données doivent être vérifiées ce qui implique que nous aurons à écrire une méthode validate dans la classe FormulaireBean. La méthode validate du formulaire est appelée par le contrôleur Struts avant que la servlet /main soit appelée. Elle rend comme résultat un objet de type ActionErrors qui est analogue à une liste d'erreurs. Si cette liste existe et est non vide, le contrôleur Struts s'arrêtera là et enverra comme réponse, la vue indiquée par l'attribut input. La vue recevra dans la requête la liste ActionErrors qu'elle pourra afficher avec la balise <html:errors>. Ci-dessus, nous disons qu'en cas d'erreurs, la servlet /main doit envoyer la vue /erreurs.do. Rappelons que cette vue est associée à l'URL /vues/erreurs.reponse.jsp suivante :
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<html>
<head>
<title>Personne</title>
</head>
<body>
<h2>Les erreurs suivantes se sont produites</h2>
<html:errors/>
<html:link page="/formulaire.do">
Retour au formulaire
</html:link>
</body>
</html>
La vue utilise bien la balise <html:errors> qui permettra d'afficher la liste des erreurs. Dans cette liste d'erreurs, on trouve non pas des messages d'erreurs mais des identifiants de messages présents dans le fichier référencé par la balise <message-resources> (attention : resources avec un seul s) :
La balise ci-dessous indique que le fichier contenant les messages utilisés par l'application se trouve dans le fichier WEB-INF/classes/ressources/personneressources.properties :
Que trouve-t-on dans ce fichier ? C'est un fichier de propriétés correspondant à la classe Properties de Java, c'est à dire un ensemble de lignes clé=valeur :
errors.header=<ul>
errors.footer=</ul>
personne.formulaire.nom.vide=<li>Vous devez indiquer un nom</li>
personne.formulaire.age.incorrect=<li>L'âge [{0}] est incorrect</li>
Ce fichier de messages a au moins deux fonctions :
- il permet de changer les messages de l'application sans avoir à la recompiler
- il permet l'internationalisation des applications Struts. On peut en effet créer plusieurs fichiers de ressources, un par langue. Struts utilisera automatiquement le bon fichier de messages à condition de respecter certaines normes dans le nommage de ces fichiers.
- Si la méthode validate du formulaire rend une liste d'erreurs vide, alors le constrôleur Struts appelle la méthode execute de la servlet ForwardAction. Il est important de comprendre ici que lorsque la méthode execute de la servlet s'exécute c'est que les données du formulaire ont été considérées comme valide (si bien sûr elles ont été vérifiées par validate="true"). C'est dans la méthode execute de la servlet associée à l'action que le développeur traite réellement le formulaire. C'est là que va se trouver le coeur du traitement (logique applicative, utilisation de classes métier et de classes d'accès aux données). Au final, la méthode rend un résultat de type ActionForward qui indique au constructeur quelle vue doit être envoyée en réponse au client. Ici nous avons utilisé l'action prédéfinie ForwardAction de Struts. Sa méthode execute se contente de rendre un ActionForward pointant sur l'URL indiquée par l'attrinut parameter :
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Si donc, les données du formulaire sont valides alors l'action /main renverra la vue /vues/main.html que nous avons déjà utilisée.
3.2. La nouvelle classe FormulaireBean
Nous avons déjà créé une première version de la classe FormulaireBean chargée de mémoriser les donnée (nom,age) du formulaire formulaire.personne.jsp. Cette version ne vérifiait pas la validité des données. Maintenant, nous devons le faire puisque nous avons indiqué dans le fichier struts-config.xml que les données du formulaire devaient être vérifiées (validate="true") avant d'être transmises à la servlet ForwardAction. Le code de la classe devient le suivant :
package istia.st.struts.personne;
import javax.servlet.http.*;
import org.apache.struts.action.*;
public class FormulaireBean
extends ActionForm {
// nom
private String nom = null;
public String getNom() {
return nom;
}
public void setNom(String nom) {
this.nom = nom;
}
// age
private String age = null;
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
// validation
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestion des erreurs
ActionErrors erreurs = new ActionErrors();
// le nom doit être non vide
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// l'âge doit être un entier positif
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// l'âge doit être un entier positif
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// on rend la liste des erreurs
}
} //if
// on rend la liste d'erreurs
return erreurs;
}
}
La nouveauté réside dans l'écriture de la méthode validate. Celle-ci est appelée par le contrôleur Struts après que celui-ci ait mis dans les attributs nom et age de la classe, les valeurs des champs du formulaire de même nom. Elle doit vérifier la validité des attributs nom et age. Le code ci-dessus est assez simple à comprendre :
- une liste d'erreurs (ActionErrors erreurs) vide est créée
- le champ nom est vérifié. S'il est vide, une erreur est ajoutée à la liste erreurs à l'aide de la méthode ActionErrors.add("clé", ActionError).
- on fait de même si le champ age n'est pas un nombre entier.
- la méthode validate rend au contrôleur Struts la liste d'erreurs (ActionErrors erreurs). Si erreurs est égal à null ou si erreurs.size() est égal à 0, le contrôleur considère qu'il n'y a pas eu d'erreurs. Il fera alors exécuter la méthode execute de la classe Action associée à l'action (type="org.apache.struts.actions.ForwardAction"). Sinon, il renverra la vue associée au cas d'erreurs dans le formulaire (input="/erreurs.do").
On ajoute une erreur à la liste ActionErrors erreurs par ActionErrors.add("cléErreur", new ActionError("cléMessage"[,param0, param1, param2, param3])). Le premier paramètre "cléErreur" sert à désigner de façon unique un élément ActionError dans la liste ActionErrors, un peu comme dans un dictionnaire. Il peut être quelconque. ActionError est un objet qu'on associe à un message d'erreur à l'aide de son constructeur ActionError(String cléMessage[,String param0, String param1, String param2, String param3]) où cléMessage est l'identifiant du message associé à l'erreur et parami jusqu'à 4 paramètres facultatifs. L'identifiant cléMessage n'est pas quelconque. C'est l'un des identifiants que l'on trouve dans le fichier désigné par la balise <message-resources> du fichier struts-config.xml :
Rappelons que ce fichier (en réalité WEB-INF/classes/ressources/personneressources.properties) contient les clés suivantes :
errors.header=<ul>
errors.footer=</ul>
personne.formulaire.nom.vide=<li>Vous devez indiquer un nom</li>
personne.formulaire.age.incorrect=<li>L'âge [{0}] est incorrect</li>
On peut vérifier que les clés de messages utilisées par la méthode validate de la classe FormulaireBean existent bien dans le fichier ci-dessus. On a utilisé la balise HTML <li> pour chaque message d'erreur afin que la balise <html:errors> les affiche comme une liste HTML. Nous avons vu que l'objet ActionError pouvait être non seulement contruit avec une clé de message mais avec des paramètres supplémentaires :
Si un ActionError a été construit avec des paramètres parami supplémentaires (jusqu'à quatre au maximum), ceux-ci sont accessibles dans le texte du message via la notation {0} à {3}. Ainsi, la méthode validate de FormulaireBean construit un ActionError avec la clé personne.formulaire.age.incorrect et le paramètre supplémentaire param0 age :
Le message associé, dans le fichier .properties des messages, à la clé personne.formulaire.age.incorrect est
Le {0} sera remplacé par la valeur de l'âge. Enfin les messages ayant les clés errors.header et errors.footer seront écrits respectivement avant et après la liste des erreurs. Ici, ces deux clés serviront à inclure les balises HTML <ul> et </ul> qui doivent entourer les balises <li>.
3.3. Les tests de validité du formulaire
Nous sommes prêts pour les test de validité du formulaire. Nous rappelons ci-dessous où doivent être placés les différents composants de l'application :
 | |
 | |
 | |
 |
3.3.1. Test 1
Relançons Tomcat pour qu'il lise les nouveaux fichiers de configuration puis demandons l'URL http://localhost:8080/strutspersonne/formulaire.do :
Explications :
- dans struts-config.html la section suivante a été exploitée :
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Si nous visualisons le code HTML de la page reçue nous voyons que la balise <form> de la page est la suivante :
Le bouton [Envoyer] qui est de type submit enverra donc les données du formulaire à l'URL /strutspersonne/main.do.
3.3.2. Test 2
Utilisons le bouton [Envoyer] en laissant vides les champs de saisie. Nous obtenons la réponse suivante :
Explications :
- comme indiqué plus haut, les données du formulaire ont été envoyées à l'URL /strutspersonne/main.do. Les sections suivantes du fichier struts-config.xml ont alors été utilisées :
<form-bean
name="frmPersonne"
type="istia.st.struts.personne.FormulaireBean"
scope="session"
/>
....
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
L'action /main a été déclenchée. Elle utilise le formulaire frmPersonne (name="frmPersonne"). Le contrôleur Struts a donc instancié, si nécessaire, un objet de la classe FormulaireBean (type="istia.st.struts.personne.FormulaireBean" dans la balise form-bean). Il a rempli les attributs nom et age de cet objet avec les champs de même nom du formulaire HTML :
<table>
<tr>
<td>Nom</td>
<td><html:text property="nom" size="20"/></td>
</tr>
<tr>
<td>Age</td>
<td><html:text property="age" size="3"/></td>
</tr>
<tr>
</table>
Ceci fait, le contrôleur Struts a appelé la méthode validate de l'objet FormulaireBean parce que l'attribut validate de l'action /main est positionné à true dans le fichier de configuration :
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
La méthode validate de la classe FormulaireBean est la suivante :
// validation
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestion des erreurs
ActionErrors erreurs = new ActionErrors();
// le nom doit être non vide
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// l'âge doit être un entier positif
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// l'âge doit être un entier positif
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// on rend la liste des erreurs
}
} //if
// on rend la liste d'erreurs
return erreurs;
}
Puisque les champs [nom] et [age] étaient vides, la méthode validate ci-dessus a généré une liste de deux erreurs qu'elle a renvoyée au contrôleur Struts. Parce qu'il y avait des erreurs, le contrôleur a ensuite renvoyé au client la vue associée à l'attribut input. Pour trouver de quelle vue il s'agissait, il a utilisé la section suivante de son fichier de configuration :
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Il a donc au final envoyé la vue /vues/erreurs.personne.jsp. Celle-ci a le code suivant :
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<html>
<head>
<title>Personne</title>
</head>
<body>
<h2>Les erreurs suivantes se sont produites</h2>
<html:errors/>
<html:link page="/formulaire.do">
Retour au formulaire
</html:link>
</body>
</html>
La balise <html:errors> fait un simple affichage de la liste des messages que le contrôleur Struts lui a envoyée. Elle utilise le fichier des messages indiqué par la balise <message-resources > :
On y trouve les clés et les messages suivants :
personne.formulaire.nom.vide=<li>Vous devez indiquer un nom</li>
personne.formulaire.age.vide=<li>Vous devez indiquer un age</li>
personne.formulaire.age.incorrect=<li>L'âge [{0}] est incorrect</li>
errors.header=<ul>
errors.footer=</ul>
- le message associée à la clé errors.header est écrit
- les messages associés aux différentes clés de la liste ActionErrors reçue sont écrits
- le message associée à la clé errors.footer est écrit
3.3.3. Test 3
Utilisons le lien [Retour au formulaire] de la page d'erreurs. Nous obtenons la page suivante :
Explications :
- le lien [Retour au formulaire] a le code HTML suivant :
Le contrôleur Struts a utilisé la section suivante se son fichier de configuration :
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Il a donc renvoyé la vue /vues/formulaire.personne.jsp.
3.3.4. Test 4
Nous remplissons le formulaire suivante puis nous utilisons le boton [Envoyer] :
Nous obtenons la réponse suivante :
Explications : ce sont les mêmes que pour le test n° 2.
3.3.5. Test 5
Nous utilisons le lien [Retour au formulaire] ci-dessus. Nous obtenons la page suivante :
Nous constatons que nous retrouvons le formulaire dans l'état où nous l'avons validé.
Explications : ce sont celles du test n° 3 avec une information supplémentaire :
- le formulaire HTML affiché a les balises suivantes :
<table>
<tr>
<td>Nom</td>
<td><html:text property="nom" size="20"/></td>
</tr>
<tr>
<td>Age</td>
<td><html:text property="age" size="3"/></td>
</tr>
<tr>
</table>
Les balises <html:text> ont deux fonctions :
- lors de l'envoi des valeurs du formulaire du client vers le serveur, les valeurs des champs de saisie du formulaire sont affectées aux champs de même nom de l'objet FormulaireBean
- lors de l'envoi par le serveur au client du code HTML du formulaire à afficher, les attributs value des champs de saisie associés aux balises <html:text> sont initialisés avec les valeurs des champs de même nom de l'objet FormulaireBean.
Nous sommes ici dans deux échanges client-serveur différents :
- dans le premier, l'utilisateur a rempli le formulaire et l'a envoyé au serveur
- dans le second, l'utilisateur a utilisé le lien [Retour au formulaire] pour revenir au formulaire.
La seule façon pour que dans le second échange, le formulaire puisse être réaffiché avec ses valeurs d'origine c'est que celles-ci soient placées dans la session du client. C'est ce qui a été demandé dans la section configurant l'action /main :
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Si nous avions mis scope="request", les données du formulaire n'auraient pas été stockées dans la session et nous n'aurions alors pas retrouvé ses valeurs dans le second échange.
3.3.6. Test 6
Revenons au formulaire pour entrer cette fois-ci des données valides :
Validons le formulaire. Nous obtenons le résultat suivant :
Explications :
- comme le bouton [Envoyer] envoie les valeurs du formulaire à l'URL /strutspersonne/main.do, on retrouve les mêmes explications que dans le test n° 2 jusqu'au retour au contrôleur Struts du résultat ActionErrors de la méthode validate de FormulaireBean. Mais ici, cette liste est vide. Le contrôleur utilise alors une nouvelle partie de la configuration de l'action /main :
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Le contrôleur Struts crée, si nécessaire, un objet du type indiqué par l'attribut type. La méthode execute de cette classe est exécutée et doit rendre un objet de type ActionForward indiquant la vue que doit envoyer le contrôleur comme réponse au client. Ici l'attribut type désigne la classe prédéfinie ForwardAction. La méthode execute de cette classe ne fait rien et se contente de rendre un objet ActionForward pointant sur la vue définie par l'attribut parameter, ici la vue /vues/main.html. C'est effectivement la vue que le contrôleur a renvoyée.
3.3.7. Test 7
On redemande la vue /formulaire.do :
On retouve le formulaire tel qu'on l'a validé. L'explication a déjà été donnée. Par configuration (scope="session") on a demandé que le formulaire reste dans la session. Ses valeurs sont donc conservées au fil des échanges client-serveur.
Nous avons presque terminé. Il nous reste à créer une action véritable pour le cas où les données du formulaire sont valides. Pour l'instant, nous avons utilisé l'action prédéfinie ForwardAction pour simplifier notre démonstration.
3.4. Nouvelle configuration de l'action /main
Nous ne changeons pas le fichier de configuration struts-config.xml actuel si ce n'est pour modifier sa section /main de la façon suivante :
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
type="istia.st.struts.personne.FormulaireAction"
>
<forward name="reponse" path="/reponse.do"/>
</action>
L'attribut type désigne maintenant une autre classe appelée FormulaireAction que nous aurons à construire. C'est la méthode execute de cette classe qui sera exécutée si les données du formulaire frmPersonne sont valides. Nous avons indiqué que la méthode execute faisait ce qu'elle avait à faire et rendait un objet de type ActionForward indiquant la vue que le contrôleur devait renvoyer au client. Il y a souvent plusieurs vues possibles selon le résultat du traitement du formulaire. La liste des différentes vues possibles est listée dans les balises <forward> incluses dans la balise <action>. La syntaxe d'une telle balise est la suivante :
nom quelconque identifiant une vue de façon unique | |
URL de la vue associée à la clé |
3.5. La classe FormulaireAction
Écrire la classe FormulaireAction consiste essentiellement à écrire sa méthode execute :
package istia.st.struts.personne;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import javax.servlet.ServletException;
public class FormulaireAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException,ServletException {
// on a un formulaire valide, sinon on ne serait pas arrivé là
FormulaireBean formulaire=(FormulaireBean)form;
request.setAttribute("nom",formulaire.getNom());
request.setAttribute("age",formulaire.getAge());
return mapping.findForward("reponse");
}//execute
}
La méthode execute reçoit quatre paramètres :
- ActionMapping mapping : un objet "image" de la configuration de l'action encours d'exécution donc ici une image de la configuration suivante :
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
type="istia.st.struts.personne.FormulaireAction"
>
<forward name="reponse" path="/reponse.do"/>
</action>
Ainsi l'action a accès aux clés associées aux vues qui peuvent être renvoyées au client à l'issue de l'action. La méthode excute devra renvoyer l'une de ces clés.
- ActionForm form : l'objet bean dans lequel se trouvent les valeurs du formulaire utilisée par l'action en cours. Ici, c'est l'objet frmPersonne de type FormulaireBean. Ainsi l'action a accès aux valeurs du formulaire.
- HttpServletRequest request : la requête du client qui a pu être enrichie par différentes servlets. L'action a ainsi à tous les paramètres de la requête initiale (request.getParameter) ainsi qu'à tous les attributs rajoutés à cette requête initiale (request.getAttribute). Dans notre exemple, la méthode execute enrichit la requête en y ajoutant le nom et l'âge. C'est parfaitement inutile ici puisque ces deux valeurs y sont déjà mais en tant que paramètres et non en tant qu'attributs. Le code est ici pour l'exemple.
- HttpServletResponse response : la réponse qui sera envoyée au client. L'action pourrait enrichir cette réponse. Ici elle ne le fait pas.
Ici, nous sommes dans un cas particulier. La méthode execute n'a quasiment rien à faire. Elle doit simplement indiquer que la vue suivante est la vue /reponse.do et mettre dans la requête que cette vue recevra les information nom et age que cette vue doit afficher. Elle le fait au moyen de la méthode findForward de la class ActionMapping qui admet pour paramètre une des clés trouvées dans les balises forward de la cconfiguration de l'action. Ici, il n'y a qu'une telle balise :
Notre méthode execute rend donc un ActionForward ayant "reponse" comme clé pour indiquer que la vue /reponse.do doit être envoyée.
3.6. Tests de FormulaireAction
Nous compilons la classe précédente avec Jbuilder et plaçons le .class généré dans WEB-INF/classes :
Nous modifions la vue /vues/reponse.personne.jsp :
<%
// on récupère les données nom, age
String nom=(String)request.getAttribute("nom");
String age=(String)request.getAttribute("age");
%>
<html>
<head>
<title>Personne</title>
</head>
<body>
<h2>Personne - réponse</h2>
<hr>
<table>
<tr>
<td>Nom</td>
<td><%= nom %>
</tr>
<tr>
<td>Age</td>
<td><%= age %>
</tr>
</table>
<html:link page="/formulaire.do">
Retour au formulaire
</html:link>
</body>
</html>
La vue récupère les informations nom et age dans les attributs de la requête qu'il reçoit. Nous demandons le formulaire à l'URL http://localhost:8080/strutspersonne/formulaire.do puis nous le remplissons :
Nous utilisons le bouton [Envoyer] et nous obtenons la réponse suivante :
Explications :
- on reprendra l'explication donnée pour le test n° 2 pour le début du processus. rappelons la configuration de l'action /main :
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
type="istia.st.struts.personne.FormulaireAction"
>
<forward name="reponse" path="/reponse.do"/>
</action>
- après envoi du formulaire au contrôleur à l'URL /main.do, celui-ci a construit ou recyclé un objet frmPersonne de type FormulaireBean et y a mis les valeurs du formulaire
- la méthode validate de l' objet frmPersonne a été appelée. Les données étant valides, la méthode validate a rendu une liste ActionErrors vide.
- un objet FormulaireAction a été créé ou recyclé et sa méthode execute appelée. Celle-ci a rendu un objet ActionForward avec la clé "reponse".
- le contrôleur a alors envoyé la vue associée à la clé reponse, c.a.d. /reponse.do et donc /vues/reponse.personne.jsp.
- la vue reponse.personne.jsp s'est affichée avec les valeurs mises dans la requête par la méthode execute de l'objet FormulaireAction.
3.7. Conclusion
Nous avons construit une application complète mais simple. Lorsqu'on la met en oeuvre réellement avec Struts, Tomcat, Jbuilder on a de très nombreuses occasions de faire des erreurs, notamment dans les fichiers XML de configuration de l'application. De prime abord, il peut paraître plus simple de construire cette application sans Struts avec une servlet et des pages JSP. Pour le débutant c'est probablement vrai. Au fil de l'expérience il devient plus simple de développer avec Struts. De nombreuses entreprises imposent la méthodologie Struts pour leurs développements web pour les raisons suivantes :
- Struts respecte le modèle MVC
- lorsque tous les développeurs travaillent de la même façon, la maintenance des applications devient plus simple parce qu'elles ont une architecture standard.