3. Elaborazione del modulo da parte del controller
Ci concentreremo ora su come il controller elabora i valori del modulo quando l'utente fa clic sul pulsante [Invia] nel modulo.
3.1. Il file struts-config.xml
Il nuovo file di configurazione struts-config.xml per il controller Struts ha questo aspetto:
<?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>
Abbiamo evidenziato le modifiche:
- appare una sezione <form-beans>. Viene utilizzata per definire le classi associate a ciascuno dei moduli dell'applicazione. Il numero di tag <form-bean> deve corrispondere al numero di moduli presenti nell'applicazione. In questo caso, abbiamo un solo modulo, quindi c'è una sola sezione <form-bean>. Per ogni modulo, dobbiamo definire:
- il suo nome (attributo name)
- il nome della classe derivata da ActionForm responsabile della memorizzazione dei valori del modulo (attributo type)
Questi due attributi non possono essere arbitrari. Devono corrispondere a quelli utilizzati nel tag <html:form> nel codice HTML del modulo. Ricordiamo il codice per il modulo (name, age):
Il modulo deve essere dichiarato allo stesso modo nel file struts-config.html. Ecco come si procede:
- La configurazione dell'azione /main è cambiata. Questa azione è responsabile dell'elaborazione dei valori del modulo. Pertanto, dobbiamo fornire le informazioni di cui ha bisogno riguardo al modulo:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Il servlet /main elaborerà un modulo, al quale deve essere assegnato un nome. L'attributo name si occupa di questo. Questo nome deve fare riferimento all'attributo name di una delle sezioni <form-bean>, in questo caso frmPersonne.
L'attributo scope="session" indica che i valori del modulo devono essere memorizzati nella sessione. Ciò non è sempre necessario. In questo caso, lo è. Infatti, nelle viste /reponse.do e /erreurs.do, troviamo dei link che rimandano al modulo. In entrambi i casi, vogliamo visualizzare il modulo con i valori inseriti dall'utente durante un precedente scambio client-server. Da qui la necessità di memorizzare il modulo nella sessione.
L'attributo validate indica se il metodo validate dell'oggetto frmPersonne debba essere chiamato o meno. Questo metodo viene utilizzato per verificare la validità dei dati del modulo. Qui specifichiamo che i dati devono essere verificati, il che significa che dovremo scrivere un metodo validate nella classe FormulaireBean. Il metodo validate del modulo viene chiamato dal controller Struts prima che venga invocato il servlet /main. Esso restituisce un oggetto ActionErrors, che è analogo a un elenco di errori. Se questo elenco esiste e non è vuoto, il controller Struts si fermerà lì e invierà come risposta la vista specificata dall’attributo input. La vista riceverà l'elenco ActionErrors nella richiesta, che potrà visualizzare utilizzando il tag <html:errors>. Sopra, specifichiamo che in caso di errori, il servlet /main deve inviare la vista /errors.do. Ricordiamo che questa vista è associata al seguente URL: /views/errors.response.jsp:
<%@ 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 vista utilizza correttamente il tag <html:errors>, che visualizzerà l'elenco degli errori. In questo elenco di errori non troverete messaggi di errore, ma identificatori di messaggi presenti nel file a cui fa riferimento il tag <message-resources> (nota: risorse con una sola "s"):
Il tag riportato di seguito indica che il file contenente i messaggi utilizzati dall'applicazione si trova nel file WEB-INF/classes/ressources/personneressources.properties:

Cosa contiene questo file? Si tratta di un file di proprietà corrispondente alla classe Java Properties, ovvero un insieme di righe chiave=valore:
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>
Questo file di messaggi ha almeno due funzioni:
- consente di modificare i messaggi dell'applicazione senza doverla ricompilare
- consente l'internazionalizzazione delle applicazioni Struts. È possibile creare più file di risorse, uno per ogni lingua. Struts utilizzerà automaticamente il file di messaggi corretto, purché vengano seguite determinate convenzioni di denominazione.
- Se il metodo validate del modulo restituisce un elenco di errori vuoto, il controller Struts chiama il metodo execute del servlet ForwardAction. È importante comprendere che quando viene eseguito il metodo execute del servlet, significa che i dati del modulo sono stati ritenuti validi (a condizione, ovviamente, che siano stati convalidati tramite validate="true"). È all'interno del metodo execute del servlet associato all'azione che lo sviluppatore elabora effettivamente il modulo. È qui che avviene il nucleo dell'elaborazione (logica dell'applicazione, uso delle classi di business e delle classi di accesso ai dati). In definitiva, il metodo restituisce un oggetto ActionForward che indica al renderer quale vista inviare al client. Qui abbiamo utilizzato l'azione ForwardAction predefinita di Struts. Il suo metodo execute restituisce semplicemente un ActionForward che punta all'URL specificato dall'attributo parameter:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Quindi, se i dati del modulo sono validi, l'azione /main restituirà la vista /vues/main.html che abbiamo già utilizzato.
3.2. La nuova classe FormBean
Abbiamo già creato una versione iniziale della classe FormBean responsabile della memorizzazione dei dati (nome, età) provenienti dal modulo formulaire.personne.jsp. Questa versione non convalidava i dati. Ora dobbiamo farlo poiché abbiamo specificato nel file struts-config.xml che i dati del modulo devono essere convalidati (validate="true") prima di essere passati al servlet ForwardAction. Il codice della classe diventa il seguente:
package istia.st.struts.personne;
import javax.servlet.http.*;
import org.apache.struts.action.*;
public class FormulaireBean
extends ActionForm {
// name
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) {
// error management
ActionErrors erreurs = new ActionErrors();
// name must be non-empty
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// age must be a positive integer
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// age must be a positive integer
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// return the list of errors
}
} //if
// return the error list
return erreurs;
}
}
La novità risiede nell'implementazione del metodo validate. Questo metodo viene chiamato dal controller Struts dopo aver popolato gli attributi name e age della classe con i valori provenienti dai campi del modulo con lo stesso nome. Deve verificare la validità degli attributi name e age. Il codice sopra riportato è piuttosto semplice:
- viene creato un elenco di errori vuoto (ActionErrors errors)
- viene controllato il campo name. Se è vuoto, viene aggiunto un errore all'elenco degli errori utilizzando il metodo ActionErrors.add("key", ActionError).
- Lo stesso viene fatto se il campo age non è un numero intero.
- il metodo validate restituisce l'elenco degli errori (ActionErrors errors) al controller Struts. Se errors è nullo o se errors.size() è 0, il controller considera che non ci siano stati errori. Eseguirà quindi il metodo execute della classe Action associata all'azione (type="org.apache.struts.actions.ForwardAction"). Altrimenti, restituirà la vista associata agli errori del modulo (input="/errors.do").
Un errore viene aggiunto all'elenco ActionErrors tramite ActionErrors.add("errorKey", new ActionError("messageKey"[,param0, param1, param2, param3])). Il primo parametro, "errorKey", serve a identificare in modo univoco un elemento ActionError nell'elenco ActionErrors, proprio come in un dizionario. Può essere una stringa qualsiasi. ActionError è un oggetto associato a un messaggio di errore tramite il suo costruttore ActionError(String errorKey[,String param0, String param1, String param2, String param3]), dove errorKey è l'identificatore del messaggio associato all'errore e fino a 4 parametri opzionali. L'identificatore keyMessage non è arbitrario. È uno degli identificatori presenti nel file specificato dal tag <message-resources> nel file struts-config.xml:
Si noti che questo file (in realtà WEB-INF/classes/resources/personneressources.properties) contiene le seguenti chiavi:
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>
Possiamo verificare che le chiavi dei messaggi utilizzate dal metodo validate della classe FormBean esistano effettivamente nel file sopra riportato. Abbiamo utilizzato il tag HTML <li> per ogni messaggio di errore in modo che il tag <html:errors> li visualizzi come un elenco HTML. Abbiamo visto che l'oggetto ActionError può essere costruito non solo con una chiave di messaggio, ma anche con parametri aggiuntivi:
Se un ActionError è stato costruito con parametri aggiuntivi (fino a un massimo di quattro), questi sono accessibili nel testo del messaggio tramite la notazione da {0} a {3}. Pertanto, il metodo validate di FormulaireBean costruisce un ActionError con la chiave personne.formulaire.age.incorrect e il parametro aggiuntivo param0 age:
Il messaggio associato alla chiave **person.form.age.incorrect** nel file .properties è
Il {0} verrà sostituito dal valore dell'età. Infine, i messaggi con le chiavi errors.header ed errors.footer verranno scritti rispettivamente prima e dopo l'elenco degli errori. In questo caso, queste due chiavi verranno utilizzate per includere i tag HTML <ul> e </ul>, che devono racchiudere i tag <li>.
3.3. Test di convalida del modulo
Siamo pronti a testare la validità del modulo. Di seguito è riportato un promemoria su dove devono essere posizionati i vari componenti dell'applicazione:
![]() | |
![]() | |
![]() | |
![]() |
3.3.1. Test 1
Riavvia Tomcat in modo che legga i nuovi file di configurazione, quindi inserisci l'URL http://localhost:8080/strutspersonne/formulaire.do:

Spiegazioni:
- In struts-config.html è stata utilizzata la seguente sezione:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Se visualizziamo il codice HTML della pagina ricevuta, vediamo che il tag <form> nella pagina è il seguente:
Il pulsante [Invia], che è di tipo submit, invierà quindi i dati del modulo all'URL /strutspersonne/main.do.
3.3.2. Test 2
Proviamo a utilizzare il pulsante [Invia] lasciando i campi di immissione vuoti. Otteniamo la seguente risposta:

Spiegazioni:
- Come indicato sopra, i dati del modulo sono stati inviati all'URL /strutspersonne/main.do. Sono state quindi utilizzate le seguenti sezioni del file struts-config.xml:
<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"
/>
È stata attivata l'azione /main. Essa utilizza il modulo frmPersonne (name="frmPersonne"). Il controller Struts ha quindi istanziato, se necessario, un oggetto della classe FormulaireBean (type="istia.st.struts.personne.FormulaireBean" nel tag form-bean). Ha popolato gli attributi name e age di questo oggetto con i campi omonimi nel modulo 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>
Una volta fatto ciò, il controller Struts chiama il metodo validate dell'oggetto FormBean poiché l'attributo validate dell'azione /main è impostato su true nel file di configurazione:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Il metodo validate della classe FormBean è il seguente:
// validation
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// error management
ActionErrors erreurs = new ActionErrors();
// name must be non-empty
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// age must be a positive integer
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// age must be a positive integer
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// return the list of errors
}
} //if
// return the error list
return erreurs;
}
Poiché i campi [name] e [age] erano vuoti, il metodo validate sopra riportato ha generato un elenco di due errori, che ha restituito al controller Struts. A causa degli errori, il controller ha quindi restituito al client la vista associata all'attributo di input. Per determinare quale vista fosse, ha utilizzato la seguente sezione del proprio file di configurazione:
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Ha quindi inviato la vista /views/errors.person.jsp. Questa vista contiene il seguente codice:
<%@ 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>
Il tag <html:errors> visualizza semplicemente l'elenco dei messaggi che gli vengono inviati dal controller Struts. Utilizza il file dei messaggi specificato dal tag <message-resources>:
Contiene le seguenti chiavi e messaggi:
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>
- Il messaggio associato alla chiave errors.header viene scritto
- i messaggi associati alle varie chiavi nell'elenco ActionErrors ricevuto vengono scritti
- viene scritto il messaggio associato alla chiave errors.footer
3.3.3. Test 3
Utilizziamo il link [Torna al modulo] nella pagina di errore. Otteniamo la seguente pagina:

Spiegazioni:
- Il link [Torna al modulo] ha il seguente codice HTML:
Il controller Struts ha utilizzato la seguente sezione dal proprio file di configurazione:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Ha quindi restituito la vista /views/form.person.jsp.
3.3.4. Test 4
Compiliamo il seguente modulo e poi facciamo clic sul pulsante [Invia]:

Otteniamo la seguente risposta:

Spiegazioni: sono le stesse del Test 2.
3.3.5. Test 5
Clicchiamo sul link [Torna al modulo] in alto. Vediamo la pagina seguente:

Notiamo che il modulo si trova nello stesso stato di quando lo abbiamo inviato.
Spiegazioni: sono le stesse del Test n. 3, con alcune informazioni aggiuntive:
- Il modulo HTML visualizzato presenta i seguenti tag:
<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>
I tag <html:text> hanno due funzioni:
- Quando si inviano i valori del modulo dal client al server, i valori dei campi di input del modulo vengono assegnati ai campi con lo stesso nome nell'oggetto FormBean
- quando il server invia al client il codice HTML del modulo da visualizzare, gli attributi value dei campi di input associati ai tag <html:text> vengono inizializzati con i valori dei campi con lo stesso nome nell'oggetto FormBean.
Qui abbiamo due diverse interazioni client-server:
- Nella prima, l'utente ha compilato il modulo e lo ha inviato al server
- nella seconda, l'utente ha cliccato sul link [Torna al modulo] per tornare al modulo.
L'unico modo per far sì che il modulo venga visualizzato nuovamente con i valori originali nella seconda interazione è che tali valori siano memorizzati nella sessione del client. Questo è ciò che è stato specificato nella sezione relativa alla configurazione dell'azione /main:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Se avessimo impostato scope="request", i dati del modulo non sarebbero stati memorizzati nella sessione e non avremmo potuto recuperarne i valori nel secondo scambio.
3.3.6. Test 6
Torniamo al modulo e inseriamo questa volta dei dati validi:

Inviare il modulo. Otteniamo il seguente risultato:

Spiegazioni:
- Poiché il pulsante [Invia] invia i valori del modulo all'URL /strutspersonne/main.do, valgono le stesse spiegazioni del Test 2 fino a quando il controller Struts riceve il risultato ActionErrors dal metodo validate di FormBean. Ma in questo caso, l'elenco è vuoto. Il controller utilizza quindi una nuova parte della configurazione dell'azione /main:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Il controller Struts crea, se necessario, un oggetto del tipo specificato dall'attributo type. Viene eseguito il metodo execute di questa classe, che deve restituire un oggetto ActionForward indicando la vista che il controller deve inviare come risposta al client. In questo caso, l'attributo type fa riferimento alla classe predefinita ForwardAction. Il metodo execute di questa classe non fa nulla e restituisce semplicemente un oggetto ActionForward che punta alla vista definita dall'attributo parameter, in questo caso la vista /vues/main.html. Questa è infatti la vista che il controller ha restituito.
3.3.7. Test 7
Richiediamo nuovamente la vista /form.do:

Vediamo il modulo esattamente come lo abbiamo inviato. La spiegazione è già stata fornita. Tramite la configurazione (scope="session"), abbiamo specificato che il modulo deve rimanere nella sessione. I suoi valori vengono quindi conservati durante gli scambi client-server.
Abbiamo quasi finito. Dobbiamo ancora creare un'azione adeguata per quando i dati del modulo sono validi. Per ora, abbiamo utilizzato l'azione predefinita ForwardAction per semplificare la nostra dimostrazione.
3.4. Nuova configurazione per l'azione /main
Non modifichiamo il file di configurazione struts-config.xml attuale, tranne che per modificare la sua sezione /main come segue:
<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'attributo type ora fa riferimento a un'altra classe chiamata FormAction, che dovremo implementare. È il metodo execute di questa classe che verrà chiamato se i dati nel modulo frmPersonne sono validi. Abbiamo specificato che il metodo execute esegue il proprio compito e restituisce un oggetto ActionForward che indica la vista che il controller deve rinviare al client. Spesso esistono diverse viste possibili a seconda del risultato dell'elaborazione del modulo. L'elenco delle viste possibili è specificato all'interno dei tag <forward> inclusi nel tag <action>. La sintassi di tale tag è la seguente:
qualsiasi nome che identifichi in modo univoco una vista | |
URL della vista associata alla chiave |
3.5. La classe FormAction
La scrittura della classe FormAction consiste essenzialmente nella scrittura del suo metodo 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 {
// we have a valid form, otherwise we wouldn't have got here
FormulaireBean formulaire=(FormulaireBean)form;
request.setAttribute("nom",formulaire.getNom());
request.setAttribute("age",formulaire.getAge());
return mapping.findForward("reponse");
}//execute
}
Il metodo execute accetta quattro parametri:
- ActionMapping mapping: un oggetto "immagine" che rappresenta la configurazione dell'azione attualmente in esecuzione; in questo caso, un'immagine con la seguente configurazione:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
type="istia.st.struts.personne.FormulaireAction"
>
<forward name="reponse" path="/reponse.do"/>
</action>
Pertanto, l'azione ha accesso alle chiavi associate alle viste che possono essere restituite al client al termine dell'azione. Il metodo execute deve restituire una di queste chiavi.
- ActionForm form: l'oggetto bean contenente i valori del modulo utilizzati dall'azione corrente. In questo caso, si tratta dell'oggetto frmPersonne di tipo FormBean. L'azione ha quindi accesso ai valori del modulo.
- HttpServletRequest request: la richiesta del client, che potrebbe essere stata arricchita da vari servlet. L'azione ha quindi accesso a tutti i parametri della richiesta iniziale (request.getParameter) e a tutti gli attributi aggiunti a tale richiesta iniziale (request.getAttribute). Nel nostro esempio, il metodo execute arricchisce la richiesta aggiungendo il nome e l'età. Ciò è del tutto superfluo in questo caso, poiché questi due valori sono già presenti, ma come parametri anziché come attributi. Il codice è riportato qui a scopo illustrativo.
- HttpServletResponse response: la risposta che verrà inviata al client. L'azione potrebbe arricchire questa risposta. In questo caso, non lo fa.
Qui abbiamo a che fare con un caso speciale. Il metodo execute non ha praticamente nulla da fare. Deve semplicemente indicare che la vista successiva è /reponse.do e specificare nella richiesta che questa vista riceverà le informazioni relative al nome e all'età necessarie per la visualizzazione. Lo fa utilizzando il metodo findForward della classe ActionMapping, che accetta come parametro una delle chiavi presenti nei tag forward della configurazione dell'azione. Qui c'è un solo tag di questo tipo:
Il nostro metodo restituisce quindi un ActionForward con "response" come chiave per indicare che deve essere inviata la vista /response.do.
3.6. Test di FormAction
Compiliamo la classe precedente con JBuilder e inseriamo il file .class generato in WEB-INF/classes:

Modifichiamo la vista /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 vista recupera le informazioni relative al nome e all'età dagli attributi della richiesta che riceve. Richiediamo il modulo all'URL http://localhost:8080/strutspersonne/formulaire.do e poi lo compiliamo:

Facciamo clic sul pulsante [Invia] e riceviamo la seguente risposta:

Spiegazioni:
- Per l'inizio del processo faremo riferimento alla spiegazione fornita per il Test n. 2. Rivediamo la configurazione dell'azione /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>
- Dopo che il modulo è stato inviato al controller all'URL /main.do, il controller ha creato o riutilizzato un oggetto frmPersonne di tipo FormBean e lo ha popolato con i valori del modulo
- È stato chiamato il metodo validate dell'oggetto frmPersonne. Poiché i dati erano validi, il metodo validate ha restituito una lista ActionErrors vuota.
- È stato creato o riciclato un oggetto FormAction e ne è stato chiamato il metodo execute. Questo metodo ha restituito un oggetto ActionForward con la chiave "reponse".
- Il controller ha quindi inviato la vista associata alla chiave "reponse", ovvero /reponse.do, e quindi /vues/reponse.personne.jsp.
- La vista reponse.personne.jsp è stata visualizzata con i valori impostati nella richiesta dal metodo execute dell'oggetto FormAction.
3.7. Conclusione
Abbiamo realizzato un'applicazione completa ma semplice. Quando la si implementa concretamente con Struts, Tomcat e JBuilder, le possibilità di commettere errori sono numerose, in particolare nei file di configurazione XML dell'applicazione. A prima vista, potrebbe sembrare più semplice realizzare questa applicazione senza Struts, utilizzando un servlet e pagine JSP. Per i principianti, questo è probabilmente vero. Con l'esperienza, tuttavia, diventa più facile sviluppare con Struts. Molte aziende impongono la metodologia Struts per lo sviluppo web per i seguenti motivi:
- Struts aderisce al modello MVC
- Quando tutti gli sviluppatori lavorano allo stesso modo, la manutenzione dell'applicazione diventa più semplice perché dispongono di un'architettura standard.



