3. Elaborazione del modulo da parte del controller
Ci concentriamo ora sull’elaborazione dei valori del modulo da parte del controller quando l’utente preme il pulsante [Envoyer] del modulo.
3.1. Il file struts-config.xml
Il nuovo file di configurazione struts-config.xml del controller Struts diventa il seguente:
<?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:
- viene inserita una sezione <form-beans>. Serve a 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 una sola sezione <form-bean>. Per ogni modulo, dobbiamo definire:
- il suo nome (attributo name)
- il nome della classe derivata da ActionForm incaricata di memorizzare i valori del modulo (attributo type)
Questi due attributi non possono essere arbitrari. Devono essere identici a quelli utilizzati nel tag <html:form> del codice HTML del modulo. Ricordiamo il codice per il modulo (nome, età):
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 è incaricata di elaborare i valori del modulo. Pertanto, è necessario fornirle le informazioni di cui ha bisogno nel modulo stesso:
<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 a cui è necessario assegnare un nome. A svolgere questa funzione è l'attributo name. 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, però, lo è. Infatti, nelle viste /reponse.do e /erreurs.do sono presenti 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 serve a verificare la validità dei dati del modulo. In questo caso, specifichiamo che i dati devono essere verificati, il che implica che dovremo scrivere un metodo validate nella classe FormulaireBean. Il metodo validate del modulo viene chiamato dal controller Struts prima che venga richiamato il servlet /main. Restituisce come risultato un oggetto di tipo **ActionErrors, che è analogo a un elenco di errori. Se tale elenco esiste ed è non vuoto, il controller Struts si fermerà a quel punto e invierà come risposta la vista indicata dall’attributo input. La vista riceverà nella richiesta l’elenco ActionErrors, che potrà visualizzare tramite il tag <html:errors>. Quanto sopra indica che, in caso di errori, il servlet /main deve inviare la vista /erreurs.do. Ricordiamo che questa vista è associata alla seguente vista /URL /vues/erreurs.reponse.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 consentirà di visualizzare l'elenco degli errori. In questo elenco di errori non si trovano messaggi di errore, ma identificatori di messaggi presenti nel file a cui fa riferimento il tag <message-resources> (attenzione: resources 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 si trova in questo file? Si tratta di un file di proprietà corrispondente alla classe Properties di Java, 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. È infatti possibile creare più file di risorse, uno per ogni lingua. Struts utilizzerà automaticamente il file di messaggi corretto, a condizione che vengano rispettate determinate convenzioni nella denominazione di tali file.
- 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 il metodo `execute` del servlet viene eseguito, significa che i dati del modulo sono stati considerati validi (purché, ovviamente, siano stati verificati tramite `validate="true"`). È nel metodo `execute` del servlet associato all’azione che lo sviluppatore elabora effettivamente il modulo. È qui che si trova il cuore dell’elaborazione (logica applicativa, utilizzo di classi di business e di classi di accesso ai dati). Alla fine, il metodo restituisce un risultato di tipo ActionForward che indica al costruttore quale vista deve essere inviata in risposta al client. In questo caso abbiamo utilizzato l’azione predefinita ForwardAction di Struts. Il suo metodo `execute` si limita a restituire un ActionForward che punta al URL indicato 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 FormulaireBean
Abbiamo già creato una prima versione della classe FormulaireBean incaricata di memorizzare i dati (nome, età) del modulo formulaire.personne.jsp. Questa versione non verificava la validità dei dati. Ora dobbiamo farlo, poiché nel file struts-config.xml abbiamo specificato che i dati del modulo devono essere verificati (validate="true") prima di essere trasmessi 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 {
// nome
private String nom = null;
public String getNom() {
return nom;
}
public void setNom(String nom) {
this.nom = nom;
}
// età
private String age = null;
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
// convalida
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestione degli errori
ActionErrors erreurs = new ActionErrors();
// il cognome non deve essere vuoto
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// l'età deve essere un numero intero positivo
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// l'età deve essere un numero intero positivo
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// viene restituito l'elenco degli errori
}
} //if
// si restituisce l'elenco degli errori
return erreurs;
}
}
La novità risiede nella scrittura del metodo validate**. Questo viene chiamato dal controller Struts dopo che quest'ultimo ha assegnato agli attributi nom e age della classe i valori dei campi del modulo con lo stesso nome. Deve verificare la validità degli attributi nom e age**. Il codice sopra riportato è abbastanza semplice da comprendere:
- viene creato un elenco di errori (ActionErrors errori) vuoto
- viene verificato il campo «nome». Se è vuoto, viene aggiunto un errore all’elenco degli errori tramite il metodo ActionErrors.add("chiave", ActionError).
- Si procede allo stesso modo se il campo «età» non è un numero intero.
- Il metodo validate restituisce al controller Struts l'elenco degli errori (ActionErrors errori). Se errori è uguale a null o se erreurs.size() è uguale a 0, il controller considera che non ci siano stati errori. A quel punto farà eseguire il metodo `execute` della classe `Action` associata all’azione (type="org.apache.struts.actions.ForwardAction"). In caso contrario, restituirà la vista associata alla presenza di errori nel modulo (input="/erreurs.do").
Si aggiunge un errore all’elenco ActionErrors errori tramite ActionErrors.add("cléErreur", new ActionError("cléMessage"[,param0, param1, param2, param3])). Il primo parametro "cléErreur" serve a identificare in modo univoco un elemento ActionError nell'elenco ActionErrors, un po' come in un dizionario. Può essere qualsiasi valore. ActionError è un oggetto che viene associato a un messaggio di errore tramite il suo costruttore ActionError(String cléMessage[,String param0, String param1, String param2, String param3]), dove cléMessage è l’identificatore del messaggio associato all’errore e si possono specificare fino a 4 parametri facoltativi. L'identificatore cléMessage non è casuale. Si tratta di uno degli identificatori presenti nel file indicato dal tag <message-resources> del file struts-config.xml:
Ricordiamo che questo file (in realtà WEB-INF/classes/ressources/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>
È possibile verificare che le chiavi dei messaggi utilizzate dal metodo validate della classe FormulaireBean siano effettivamente presenti nel file sopra indicato. Per ogni messaggio di errore è stato utilizzato il tag HTML <li>, 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 creato 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 genera un ActionError con la chiave personne.formulaire.age.incorrect e il parametro aggiuntivo param0 age:
Il messaggio associato, nel file .properties dei messaggi, alla chiave personne.formulaire.age.incorrect è
Il {0} verrà sostituito dal valore dell'età. Infine, i messaggi con le chiavi errors.header e errors.footer verranno inseriti rispettivamente prima e dopo l'elenco degli errori. In questo caso, queste due chiavi serviranno a includere i tag HTML <ul> e </ul>, che devono racchiudere i tag <li>.
3.3. I test di validità del modulo
Siamo pronti per i test di validità del modulo. Ricordiamo di seguito dove devono essere posizionati i diversi componenti dell’applicazione:
 | |
 | |
 | |
 |
3.3.1. Test 1
Riavviamo Tomcat affinché legga i nuovi file di configurazione, quindi richiediamo l'http://localhost:8080/strutspersonne/formulaire.do: URL:
Spiegazioni:
- in struts-config.html è stata sfruttata 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> della pagina è il seguente:
Il pulsante [Envoyer], che è di tipo submit, invierà quindi i dati del modulo a URL /strutspersonne/main.do.
3.3.2. Test 2
Utilizziamo il pulsante [Envoyer] lasciando vuoti i campi di inserimento. Otteniamo la seguente risposta:
Spiegazioni:
- come indicato in precedenza, i dati del modulo sono stati inviati a 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 «nome» e «età» di tale oggetto con i campi omonimi del 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 ha chiamato il metodo validate dell'oggetto **FormulaireBean, 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 FormulaireBean è il seguente:
// convalida
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestione degli errori
ActionErrors erreurs = new ActionErrors();
// il nome non deve essere vuoto
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// l'età deve essere un numero intero positivo
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// l'età deve essere un numero intero positivo
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// viene restituito l'elenco degli errori
}
} //if
// si restituisce l'elenco degli errori
return erreurs;
}
Poiché i campi [nom] e [age] erano vuoti, il metodo validate sopra riportato ha generato un elenco di due errori che ha restituito al controller Struts. A causa della presenza di errori, il controller ha quindi restituito al client la vista associata all'attributo input. Per individuare di quale vista si trattasse, ha utilizzato la seguente sezione del proprio file di configurazione:
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Alla fine ha quindi inviato la vista /vues/erreurs.personne.jsp. Questa presenta 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 il controller Struts gli ha inviato. Utilizza il file dei messaggi indicato dal tag <message-resources>:
In esso sono presenti 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>
- viene scritto il messaggio associato alla chiave errors.header
- vengono scritti i messaggi associati alle diverse chiavi dell'elenco ActionErrors ricevuto
- viene scritto il messaggio associato alla chiave errors.footer
3.3.3. Test 3
Utilizziamo il link [Retour au formulaire] dalla pagina degli errori. Otteniamo la seguente pagina:
Spiegazioni:
- il link [Retour au formulaire] ha il seguente codice HTML:
Il controller Struts ha utilizzato la seguente sezione del proprio file di configurazione:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Ha quindi restituito la vista /viste/formulaire.personne.jsp.
3.3.4. Test 4
Compiliamo il seguente modulo, quindi utilizziamo il pulsante [Envoyer]:
Otteniamo la seguente risposta:
Spiegazioni: sono le stesse del test n. 2.
3.3.5. Test 5
Utilizziamo il link [Retour au formulaire] riportato sopra. Otteniamo la seguente pagina:
Notiamo che il modulo appare esattamente come lo avevamo inviato.
Spiegazioni: sono quelle del test n. 3 con un'ulteriore informazione:
- 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 i valori del modulo vengono inviati dal client al server, i valori dei campi di immissione del modulo vengono assegnati ai campi con lo stesso nome dell’oggetto FormulaireBean
- quando il server invia al client il codice HTML del modulo da visualizzare, gli attributi value dei campi di immissione associati ai tag <html:text> vengono inizializzati con i valori dei campi con lo stesso nome dell'oggetto FormulaireBean.
Si tratta in questo caso di due diversi scambi client-server:
- nel primo, l’utente ha compilato il modulo e lo ha inviato al server
- nel secondo, l'utente ha utilizzato il link [Retour au formulaire] per tornare al modulo.
L’unico modo affinché, nel secondo scambio, il modulo possa essere visualizzato nuovamente con i suoi valori originali è che questi ultimi siano inseriti nella sessione del cliente. È quanto è stato richiesto nella sezione che configura l’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 quindi potuto recuperarne i valori nel secondo scambio.
3.3.6. Test 6
Torniamo al modulo per inserire questa volta dei dati validi:
Confermiamo il modulo. Otteniamo il seguente risultato:
Spiegazioni:
- poiché il pulsante [Envoyer] invia i valori del modulo a URL /strutspersonne/main.do, si ritrovano le stesse spiegazioni del test n. 2 fino al ritorno al controller Struts del risultato ActionErrors del metodo validate di FormulaireBean. 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. Il metodo execute di questa classe viene eseguito e deve restituire un oggetto di tipo **ActionForward che indica la vista che il controller deve inviare come risposta al client. In questo caso l’attributo type indica la classe predefinita ForwardAction. Il metodo execute di questa classe non esegue alcuna operazione e si limita a restituire un oggetto **ActionForward che punta alla vista definita dall’attributo parameter, in questo caso la vista **/vues/main.html**. Si tratta effettivamente della vista che il controller ha restituito.
3.3.7. Test 7
Richiediamo nuovamente la vista /formulaire.do:
Si ritrova il modulo così come è stato convalidato. La spiegazione è già stata fornita. Tramite la configurazione (scope="session") è stato richiesto che il modulo rimanga nella sessione. I suoi valori vengono quindi conservati durante gli scambi client-server.
Abbiamo quasi finito. Resta da creare un'azione vera e propria nel caso in cui i dati del modulo siano validi. Per ora, abbiamo utilizzato l'azione predefinita ForwardAction per semplificare la nostra dimostrazione.
3.4. Nuova configurazione dell’azione /main
Non modifichiamo l’attuale file di configurazione struts-config.xml, se non 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 indica un'altra classe denominata FormulaireAction che dovremo creare. È il metodo execute di questa classe che verrà eseguito se i dati del modulo frmPersonne sono validi. Abbiamo specificato che il metodo **execute esegue le operazioni necessarie e restituisce un oggetto di tipo **ActionForward che indica la vista che il controller deve restituire al client. Spesso sono disponibili diverse viste a seconda del risultato dell’elaborazione del modulo. L’elenco delle diverse viste possibili è riportato nei tag <forward> inclusi nel tag <action>. La sintassi di tale tag è la seguente:
nome qualsiasi che identifichi in modo univoco una vista | |
URL della vista associata alla chiave |
3.5. La classe FormulaireAction
La definizione della classe FormulaireAction consiste essenzialmente nella definizione 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 {
// il modulo è valido, altrimenti non saremmo arrivati a questo punto
FormulaireBean formulaire=(FormulaireBean)form;
request.setAttribute("nom",formulaire.getNom());
request.setAttribute("age",formulaire.getAge());
return mapping.findForward("reponse");
}//esegue
}
Il metodo execute accetta quattro parametri:
- Mappatura ActionMapping: un oggetto "immagine" della configurazione dell'azione in corso di esecuzione, quindi in questo caso un'immagine della 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>
In questo modo l'azione ha accesso alle chiavi associate alle viste che possono essere restituite al client al termine dell'azione. Il metodo execute dovrà restituire una di queste chiavi.
- ActionForm form: l’oggetto bean in cui si trovano i valori del modulo utilizzato dall’azione in corso. In questo caso, si tratta dell’oggetto frmPersonne di tipo FormulaireBean. In questo modo l’azione ha accesso ai valori del modulo.
- HttpServletRequest request: la richiesta del client che può essere stata arricchita da diversi servlet. L’azione ha quindi a disposizione tutti i parametri della richiesta iniziale (request.getParameter) nonché tutti gli attributi aggiunti a tale richiesta iniziale (request.getAttribute). Nel nostro esempio, il metodo `execute` arricchisce la richiesta aggiungendovi il nome e l'età. Ciò è del tutto superfluo in questo caso, poiché questi due valori sono già presenti, ma come parametri e non come attributi. Il codice è riportato qui a titolo di esempio.
- HttpServletResponse response: la risposta che verrà inviata al client. L’azione potrebbe arricchire questa risposta. In questo caso non lo fa.
In questo caso ci troviamo di fronte a una situazione particolare. Il metodo execute non ha praticamente nulla da fare. Deve semplicemente indicare che la vista successiva è la vista **/reponse.do e specificare nella richiesta che tale vista riceverà le informazioni relative al nome e all’età che deve visualizzare. Lo fa tramite il metodo findForward della classe ActionMapping, che accetta come parametro una delle chiavi presenti nei tag forward** della configurazione dell’azione. In questo caso, c’è un solo tag di questo tipo:
Il nostro metodo execute restituisce quindi un ActionForward con la chiave «reponse» per indicare che deve essere inviata la vista /reponse.do.
3.6. Test di FormulaireAction
Compiliamo la classe precedente con JBuilder e inseriamo il file .class generato in WEB-INF/classes:
Modifichiamo la vista /vues/reponse.personne.jsp:
<%
// si recuperano i dati nome, età
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 a URL http://localhost:8080/strutspersonne/formulaire.do e lo compiliamo:
Utilizziamo il pulsante [Envoyer] e otteniamo la seguente risposta:
Spiegazioni:
- Per l'inizio del processo, riprenderemo la spiegazione fornita per il test n. 2. Ricordiamo 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 l'invio del modulo al controllore all'indirizzo URL /main.do, quest'ultimo ha creato o riutilizzato un oggetto frmPersonne di tipo FormulaireBean e vi ha inserito i valori del modulo
- è stato chiamato il metodo validate dell’oggetto frmPersonne. Poiché i dati erano validi, il metodo validate ha restituito un elenco ActionErrors vuoto.
- È stato creato o riciclato un oggetto FormulaireAction e ne è stato chiamato il metodo `execute`. Quest’ultimo ha restituito un oggetto ActionForward con la chiave "reponse".
- Il controller ha quindi inviato la vista associata alla chiave "reponse", c.a.d. /reponse.do e quindi /vues/reponse.personne.jsp.
- La vista reponse.personne.jsp è stata visualizzata con i valori inseriti nella richiesta dal metodo execute dell’oggetto FormulaireAction.
3.7. Conclusione
Abbiamo realizzato un'applicazione completa ma semplice. Quando la si implementa realmente con Struts, Tomcat e JBuilder, le possibilità di commettere errori sono numerose, in particolare nei file di configurazione dell'applicazione XML. A prima vista, potrebbe sembrare più semplice realizzare questa applicazione senza Struts, utilizzando un servlet e pagine JSP. Per un principiante questo è probabilmente vero. Con l’aumentare dell’esperienza, però, diventa più semplice sviluppare con Struts. Molte aziende impongono la metodologia Struts per i propri sviluppi web per i seguenti motivi:
- Struts rispetta il modello MVC
- quando tutti gli sviluppatori lavorano allo stesso modo, la manutenzione delle applicazioni diventa più semplice perché hanno un’architettura standard.