3. Procesamiento del formulario por parte del controlador
Ahora nos enfocamos en el procesamiento de los valores del formulario por parte del controlador cuando el usuario presione el botón [Envoyer] del formulario.
3.1. El archivo struts-config.xml
El nuevo archivo de configuración struts-config.xml del controlador Struts queda así:
<?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>
Hemos resaltado los cambios:
- aparece una sección <form-beans>. Sirve para definir las clases asociadas a cada uno de los formularios de la aplicación. Debe haber tantas etiquetas <form-bean> como formularios diferentes haya en la aplicación. Aquí solo tenemos un formulario, por lo que solo hay una sección <form-bean>. Para cada formulario, debemos definir:
- su nombre (atributo name)
- el nombre de la clase derivada de ActionForm encargada de almacenar los valores del formulario (atributo type)
Estos dos atributos no pueden ser cualquiera. Deben ser idénticos a los utilizados en la etiqueta <html:form> del código HTML del formulario. Recordemos esta para el formulario (nombre, edad):
El formulario debe declararse de la misma manera en el archivo struts-config.html. Así es como se hace aquí:
- La configuración de la acción /main ha cambiado. Esta se encarga de procesar los valores del formulario. Por lo tanto, debemos proporcionarle la información que necesita en el mismo:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
El servlet /main procesará un formulario al que hay que asignarle un nombre. El atributo name se encarga de ello. Este nombre debe hacer referencia al atributo name de una de las secciones <form-bean>, en este caso frmPersonne.
El atributo scope="session" indica que los valores del formulario deben almacenarse en la sesión. Esto no siempre es necesario. En este caso, sí lo es. De hecho, en las vistas /reponse.do y /erreurs.do encontramos enlaces que redirigen al formulario. En ambos casos, queremos mostrar el formulario con los valores ingresados por el usuario durante un intercambio anterior entre el cliente y el servidor. De ahí la necesidad de almacenar el formulario en la sesión.
El atributo validate indica si se debe llamar o no al método validate del objeto frmPersonne. Este método sirve para verificar la validez de los datos del formulario. Aquí indicamos que los datos deben verificarse, lo que implica que tendremos que escribir un método validate en la clase FormulaireBean. El método validate del formulario es invocado por el controlador Struts antes de que se llame al servlet /main. Devuelve como resultado un objeto de tipo ActionErrors, que es análogo a una lista de errores. Si esta lista existe y no está vacía, el controlador Struts se detendrá ahí y enviará como respuesta la vista indicada por el atributo input. La vista recibirá en la solicitud la lista ActionErrors, la cual podrá mostrar con la etiqueta <html:errors>. En el ejemplo anterior, indicamos que, en caso de errores, el servlet /main debe enviar la vista /erreurs.do. Recordemos que esta vista está asociada a la siguiente vista URL /vistas/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 utiliza correctamente la etiqueta <html:errors>, que permitirá mostrar la lista de errores. En esta lista de errores no se encuentran mensajes de error, sino identificadores de mensajes presentes en el archivo al que hace referencia la etiqueta <message-resources> (atención: «resources» con una sola «s»):
La etiqueta a continuación indica que el archivo que contiene los mensajes utilizados por la aplicación se encuentra en el archivo WEB-INF/classes/ressources/personneressources.properties:
¿Qué hay en este archivo? Es un archivo de propiedades que corresponde a la clase Properties de Java, es decir, un conjunto de líneas clave=valor:
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>
Este archivo de mensajes tiene al menos dos funciones:
- permite modificar los mensajes de la aplicación sin necesidad de recompilarla
- permite la internacionalización de las aplicaciones Struts. De hecho, se pueden crear varios archivos de recursos, uno por idioma. Struts utilizará automáticamente el archivo de mensajes correcto siempre y cuando se respeten ciertas normas en la nomenclatura de estos archivos.
- Si el método validate del formulario devuelve una lista de errores vacía, entonces el controlador Struts llama al método execute del servlet ForwardAction. Es importante comprender aquí que cuando se ejecuta el método `execute` del servlet, significa que los datos del formulario se han considerado válidos (siempre y cuando, por supuesto, hayan sido verificados mediante `validate="true"`). Es en el método `execute` del servlet asociado a la acción donde el desarrollador procesa realmente el formulario. Ahí es donde se encuentra el núcleo del procesamiento (lógica de aplicación, uso de clases de negocio y de clases de acceso a datos). Al final, el método devuelve un resultado de tipo ActionForward que le indica al constructor qué vista debe enviarse como respuesta al cliente. Aquí hemos utilizado la acción predefinida ForwardAction de Struts. Su método `execute` simplemente devuelve un ActionForward que apunta al URL indicado por el atributo `parameter`:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Por lo tanto, si los datos del formulario son válidos, la acción /main devolverá la vista /vistas/main.html que ya hemos utilizado.
3.2. La nueva clase FormulaireBean
Ya hemos creado una primera versión de la clase FormulaireBean encargada de almacenar los datos (nombre, edad) del formulario formulaire.personne.jsp. Esta versión no verificaba la validez de los datos. Ahora debemos hacerlo, ya que hemos indicado en el archivo struts-config.xml que los datos del formulario deben ser validados (validate="true") antes de ser transmitidos al servlet ForwardAction. El código de la clase queda así:
package istia.st.struts.personne;
import javax.servlet.http.*;
import org.apache.struts.action.*;
public class FormulaireBean
extends ActionForm {
// nombre
private String nom = null;
public String getNom() {
return nom;
}
public void setNom(String nom) {
this.nom = nom;
}
// edad
private String age = null;
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
// validación
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestión de errores
ActionErrors erreurs = new ActionErrors();
// el nombre no debe estar vacío
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// la edad debe ser un número entero positivo
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// la edad debe ser un número entero positivo
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// se devuelve la lista de errores
}
} //si
// se devuelve la lista de errores
return erreurs;
}
}
La novedad radica en la implementación del método validate. Este método es llamado por el controlador Struts después de que este haya asignado a los atributos nombre y edad de la clase los valores de los campos del formulario con los mismos nombres. Debe verificar la validez de los atributos nombre y edad. El código anterior es bastante sencillo de entender:
- se crea una lista de errores (ActionErrors errores) vacía
- se verifica el campo «nombre». Si está vacío, se agrega un error a la lista de errores mediante el método ActionErrors.add("clave", ActionError).
- Se hace lo mismo si el campo «edad» no es un número entero.
- El método validate devuelve al controlador Struts la lista de errores (ActionErrors errores). Si errores es igual a null o si erreurs.size() es igual a 0, el controlador considera que no hubo errores. A continuación, ejecutará el método `execute` de la clase `Action` asociada a la acción (type="org.apache.struts.actions.ForwardAction"). De lo contrario, devolverá la vista asociada al caso de errores en el formulario (input="/erreurs.do").
Se agrega un error a la lista ActionErrors errores mediante ActionErrors.add("cléErreur", new ActionError("cléMessage"[,param0, param1, param2, param3])). El primer parámetro «cléErreur» sirve para identificar de manera única un elemento ActionError en la lista ActionErrors, de manera similar a como se hace en un diccionario. Puede ser cualquier valor. ActionError es un objeto que se asocia a un mensaje de error mediante su constructor ActionError(String cléMessage[,String param0, String param1, String param2, String param3]), donde cléMessage es el identificador del mensaje asociado al error y se pueden pasar hasta 4 parámetros opcionales. El identificador cléMessage no es cualquiera. Es uno de los identificadores que se encuentran en el archivo designado por la etiqueta <message-resources> del archivo struts-config.xml:
Recordemos que este archivo (en realidad, WEB-INF/classes/ressources/personneressources.properties) contiene las siguientes claves:
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>
Se puede verificar que las claves de mensajes utilizadas por el método validate de la clase FormulaireBean existen efectivamente en el archivo anterior. Se utilizó la etiqueta HTML <li> para cada mensaje de error, de modo que la etiqueta <html:errors> los muestre como una lista HTML. Hemos visto que el objeto ActionError no solo se puede construir con una clave de mensaje, sino también con parámetros adicionales:
Si se ha construido un ActionError con parámetros adicionales (hasta un máximo de cuatro), se puede acceder a ellos en el texto del mensaje mediante la notación {0} a {3}. Así, el método validate de FormulaireBean genera un ActionError con la clave personne.formulaire.age.incorrect y el parámetro adicional param0, que tiene el valor:
El mensaje asociado, en el archivo .properties de mensajes, a la clave personne.formulaire.age.incorrect es
El {0} se reemplazará por el valor de la edad. Por último, los mensajes con las claves errors.header y errors.footer se escribirán, respectivamente, antes y después de la lista de errores. En este caso, estas dos claves servirán para incluir las etiquetas HTML <ul> y </ul>, que deben rodear las etiquetas <li>.
3.3. Las pruebas de validez del formulario
Estamos listos para las pruebas de validez del formulario. A continuación recordamos dónde deben colocarse los diferentes componentes de la aplicación:
 | |
 | |
 | |
 |
3.3.1. Prueba 1
Reiniciemos Tomcat para que lea los nuevos archivos de configuración y luego solicitemos el URL http://localhost:8080/strutspersonne/formulaire.do:
Explicaciones:
- en struts-config.html se aprovechó la siguiente sección:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Si observamos el código HTML de la página recibida, vemos que la etiqueta <form> de la página es la siguiente:
El botón [Envoyer], que es de tipo «submit», enviará los datos del formulario a URL /strutspersonne/main.do.
3.3.2. Prueba 2
Usemos el botón [Envoyer] dejando vacíos los campos de entrada. Obtenemos la siguiente respuesta:
Explicaciones:
- como se indicó anteriormente, los datos del formulario se enviaron a URL /strutspersonne/main.do. A continuación, se utilizaron las siguientes secciones del archivo 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"
/>
Se ha activado la acción /main. Esta utiliza el formulario frmPersonne (name="frmPersonne"). Por lo tanto, el controlador Struts ha instanciado, si fue necesario, un objeto de la clase FormulaireBean (type="istia.st.struts.personne.FormulaireBean" en la etiqueta form-bean). Ha completado los atributos «nombre» y «edad» de este objeto con los campos del mismo nombre del formulario 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 vez hecho esto, el controlador Struts llamó al método validate del objeto **FormulaireBean, ya que el atributo validate de la acción **/main está configurado como true en el archivo de configuración:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
El método validate de la clase FormulaireBean es el siguiente:
// validación
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestión de errores
ActionErrors erreurs = new ActionErrors();
// el nombre no debe estar vacío
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// la edad debe ser un número entero positivo
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// la edad debe ser un número entero positivo
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// se devuelve la lista de errores
}
} //si
// se muestra la lista de errores
return erreurs;
}
Dado que los campos [nom] y [age] estaban vacíos, el método validate anterior generó una lista de dos errores que devolvió al controlador Struts. Debido a que había errores, el controlador devolvió al cliente la vista asociada al atributo input. Para determinar de qué vista se trataba, utilizó la siguiente sección de su archivo de configuración:
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Así que, al final, envió la vista /vistas/erreurs.personne.jsp. Esta tiene el siguiente código:
<%@ 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 etiqueta <html:errors> simplemente muestra la lista de mensajes que el controlador Struts le ha enviado. Utiliza el archivo de mensajes indicado por la etiqueta <message-resources>:
En él se encuentran las claves y los mensajes siguientes:
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>
- se escribe el mensaje asociado a la clave errors.header
- se escriben los mensajes asociados a las diferentes claves de la lista ActionErrors recibida
- Se escribe el mensaje asociado a la clave errors.footer
3.3.3. Prueba 3
Usemos el enlace [Retour au formulaire] de la página de errores. Obtenemos la siguiente página:
Explicaciones:
- el enlace [Retour au formulaire] tiene el siguiente código HTML:
El controlador Struts utilizó la siguiente sección de su archivo de configuración:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Por lo tanto, devolvió la vista /vistas/formulaire.personne.jsp.
3.3.4. Prueba 4
Llenamos el siguiente formulario y luego presionamos el botón [Envoyer]:
Obtenemos la siguiente respuesta:
Explicaciones: son las mismas que para la prueba n.º 2.
3.3.5. Prueba 5
Utilizamos el enlace [Retour au formulaire] mencionado anteriormente. Obtenemos la siguiente página:
Observamos que el formulario aparece tal como lo validamos.
Explicaciones: son las mismas que en la prueba n.º 3, con una información adicional:
- el formulario HTML que se muestra tiene las siguientes etiquetas:
<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>
Las etiquetas <html:text> tienen dos funciones:
- al enviar los valores del formulario del cliente al servidor, los valores de los campos de entrada del formulario se asignan a los campos del mismo nombre del objeto FormulaireBean
- al enviar el servidor al cliente el código HTML del formulario que se va a mostrar, los atributos «value» de los campos de entrada asociados a las etiquetas <html:text> se inicializan con los valores de los campos del mismo nombre del objeto FormulaireBean.
Aquí nos encontramos ante dos intercambios cliente-servidor diferentes:
- en el primero, el usuario completó el formulario y lo envió al servidor
- en el segundo, el usuario utilizó el enlace [Retour au formulaire] para regresar al formulario.
La única forma de que, en la segunda interacción, el formulario se pueda volver a mostrar con sus valores originales es que estos se almacenen en la sesión del cliente. Esto es lo que se ha solicitado en la sección que configura la acción /main:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Si hubiéramos puesto scope="request", los datos del formulario no se habrían almacenado en la sesión y, por lo tanto, no habríamos podido recuperar sus valores en el segundo intercambio.
3.3.6. Prueba 6
Volvamos al formulario para ingresar esta vez datos válidos:
Enviemos el formulario. Obtenemos el siguiente resultado:
Explicaciones:
- dado que el botón [Envoyer] envía los valores del formulario a URL /strutspersonne/main.do, encontramos las mismas explicaciones que en la prueba n.º 2 hasta el momento en que el resultado ActionErrors del método validate de FormulaireBean regresa al controlador Struts. Pero aquí, esta lista está vacía. El controlador utiliza entonces una nueva parte de la configuración de la acción /main:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
El controlador Struts crea, si es necesario, un objeto del tipo indicado por el atributo type. Se ejecuta el método execute de esta clase, el cual debe devolver un objeto de tipo ActionForward que indique la vista que el controlador debe enviar como respuesta al cliente. En este caso, el atributo type hace referencia a la clase predefinida ForwardAction. El método execute de esta clase no hace nada y simplemente devuelve un objeto **ActionForward que apunta a la vista definida por el atributo parameter**, en este caso la vista **/vues/main.html**. Esta es, de hecho, la vista que el controlador ha devuelto.
3.3.7. Prueba 7
Volvemos a solicitar la vista /formulaire.do:
Vemos el formulario tal como lo validamos. Ya se ha explicado esto. Mediante la configuración (scope="session") se ha solicitado que el formulario permanezca en la sesión. Por lo tanto, sus valores se conservan a lo largo de los intercambios entre el cliente y el servidor.
Ya casi hemos terminado. Nos queda crear una acción real para el caso en que los datos del formulario sean válidos. Por ahora, hemos utilizado la acción predefinida ForwardAction para simplificar nuestra demostración.
3.4. Nueva configuración de la acción /main
No modificamos el archivo de configuración actual struts-config.xml, salvo para cambiar su sección /main de la siguiente manera:
<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>
El atributo «type» ahora apunta a otra clase llamada FormulaireAction que tendremos que crear. Es el método «execute» de esta clase el que se ejecutará si los datos del formulario frmPersonne son válidos. Hemos indicado que el método **execute hacía lo que debía y devolvía un objeto de tipo **ActionForward que indicaba la vista que el controlador debía enviar al cliente. A menudo hay varias vistas posibles según el resultado del procesamiento del formulario. La lista de las diferentes vistas posibles se encuentra en las etiquetas <forward> incluidas dentro de la etiqueta <action>. La sintaxis de dicha etiqueta es la siguiente:
cualquier nombre que identifique una vista de manera única | |
URL de la vista asociada a la clave |
3.5. La clase FormulaireAction
Escribir la clase FormulaireAction consiste esencialmente en escribir su método 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 {
// tenemos un formulario válido; de lo contrario, no habríamos llegado hasta aquí
FormulaireBean formulaire=(FormulaireBean)form;
request.setAttribute("nom",formulaire.getNom());
request.setAttribute("age",formulaire.getAge());
return mapping.findForward("reponse");
}//ejecutar
}
El método execute recibe cuatro parámetros:
- Mapeo ActionMapping: un objeto «imagen» de la configuración de la acción que se está ejecutando; por lo tanto, en este caso, una imagen de la siguiente configuración:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
type="istia.st.struts.personne.FormulaireAction"
>
<forward name="reponse" path="/reponse.do"/>
</action>
De esta manera, la acción tiene acceso a las claves asociadas a las vistas, las cuales pueden devolverse al cliente al finalizar la acción. El método que se ejecute deberá devolver una de estas claves.
- ActionForm form: el objeto bean en el que se encuentran los valores del formulario utilizado por la acción en curso. En este caso, es el objeto frmPersonne de tipo FormulaireBean. De esta manera, la acción tiene acceso a los valores del formulario.
- HttpServletRequest request: la solicitud del cliente, que puede haber sido enriquecida por diferentes servlets. De este modo, la acción tiene acceso a todos los parámetros de la solicitud inicial (request.getParameter), así como a todos los atributos añadidos a dicha solicitud inicial (request.getAttribute). En nuestro ejemplo, el método `execute` enriquece la solicitud agregándole el nombre y la edad. Esto es totalmente innecesario aquí, ya que estos dos valores ya están presentes, pero como parámetros y no como atributos. El código se incluye aquí a modo de ejemplo.
- HttpServletResponse response: la respuesta que se enviará al cliente. La acción podría enriquecer esta respuesta. Aquí no lo hace.
Aquí nos encontramos ante un caso particular. El método **execute prácticamente no tiene nada que hacer. Simplemente debe indicar que la vista siguiente es la vista **/reponse.do** e incluir en la solicitud que esta vista recibirá la información de nombre y edad que debe mostrar. Lo hace mediante el método findForward de la clase ActionMapping, que admite como parámetro una de las claves que se encuentran en las etiquetas «forward»** de la configuración de la acción. Aquí solo hay una etiqueta de este tipo:
Por lo tanto, nuestro método ejecuta y devuelve un ActionForward con la clave «respuesta» para indicar que se debe enviar la vista /reponse.do.
3.6. Pruebas de FormulaireAction
Compilamos la clase anterior con JBuilder y colocamos el archivo .class generado en WEB-INF/classes:
Modificamos la vista /vistas/reponse.personne.jsp:
<%
// se recuperan los datos: nombre, edad
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 la información de nombre y edad de los atributos de la solicitud que recibe. Solicitamos el formulario a URL http://localhost:8080/strutspersonne/formulaire.do y luego lo llenamos:
Utilizamos el botón [Envoyer] y obtenemos la siguiente respuesta:
Explicaciones:
- Para el inicio del proceso, utilizaremos la explicación dada para la prueba n.º 2. Recordemos la configuración de la acción /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>
- Tras enviar el formulario al controlador en URL /main.do, este creó o reutilizó un objeto frmPersonne de tipo FormulaireBean y le asignó los valores del formulario
- Se invocó el método validate del objeto frmPersonne. Dado que los datos eran válidos, el método validate devolvió una lista ActionErrors vacía.
- Se creó o recicló un objeto FormulaireAction y se invocó su método `execute`. Este devolvió un objeto ActionForward con la clave «respuesta».
- A continuación, el controlador envió la vista asociada a la clave «respuesta», c.a.d. /reponse.do y, por lo tanto, /vistas/reponse.personne.jsp.
- La vista reponse.personne.jsp se mostró con los valores introducidos en la solicitud mediante el método execute del objeto FormulaireAction.
3.7. Conclusión
Hemos creado una aplicación completa pero sencilla. Al implementarla realmente con Struts, Tomcat y JBuilder, hay muchas oportunidades de cometer errores, especialmente en los archivos de configuración de la aplicación XML. A primera vista, puede parecer más sencillo desarrollar esta aplicación sin Struts, utilizando un servlet y páginas JSP. Para un principiante, probablemente sea así. Sin embargo, a medida que se adquiere experiencia, se vuelve más sencillo desarrollar con Struts. Muchas empresas imponen la metodología Struts para sus desarrollos web por las siguientes razones:
- Struts respeta el modelo MVC
- cuando todos los desarrolladores trabajan de la misma manera, el mantenimiento de las aplicaciones se vuelve más sencillo porque tienen una arquitectura estándar.