3. Procesamiento del formulario por parte del controlador
Ahora nos centramos en el procesamiento de los valores del formulario por parte del controlador cuando el usuario pulse 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. En este caso, 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 este para el formulario (nombre, edad):
El formulario debe declararse de la misma manera en el archivo struts-config.html. Esto es lo que 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 introducidos 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, que 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 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 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 siguiente 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 correspondiente 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 cambiar los mensajes de la aplicación sin tener que 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 adecuado siempre que se respeten ciertas normas en la denominación de dichos 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 es porque los datos del formulario se han considerado válidos (siempre que, 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 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 se limita a devolver 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 /vues/main.html que ya hemos utilizado.
3.2. La nueva clase FormulaireBean
Ya hemos creado una primera version de la clase FormulaireBean encargada de almacenar los datos (nombre, edad) del formulario formulaire.personne.jsp. Esta clase version 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 verificarse (validate="true") antes de transmitirse 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 {
// 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) {
// 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
}
} //if
// se devuelve la lista de errores
return erreurs;
}
}
La novedad reside en la escritura del método validate. Este es invocado 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 del mismo nombre. 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 comprueba el campo «nombre». Si está vacío, se añade 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 ha habido 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 a los casos de error en el formulario (input="/erreurs.do").
Añadimos 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 designar de forma única un elemento ActionError en la lista ActionErrors, de forma similar a como se hace en un diccionario. Puede ser cualquiera. 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 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/resources/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 comprobar que las claves de mensajes utilizadas por el método validate de la clase FormulaireBean existen efectivamente en el archivo anterior. Se ha utilizado 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 generado 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:
El mensaje asociado, en el archivo .properties de mensajes, a la clave personne.formulaire.age.incorrect es
El {0} se sustituirá 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
Ya 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 ha explotado la siguiente sección:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Si visualizamos 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á por tanto los datos del formulario a URL /strutspersonne/main.do.
3.3.2. Prueba 2
Utilicemos el botón [Envoyer] dejando vacíos los campos de entrada. Obtenemos la siguiente respuesta:
Explicaciones:
- como se ha indicado anteriormente, los datos del formulario se han enviado a URL /strutspersonne/main.do. A continuación, se han utilizado 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 era necesario, un objeto de la clase FormulaireBean (type="istia.st.struts.personne.FormulaireBean" en la etiqueta form-bean). Ha rellenado 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 porque el atributo validate de la acción /main está establecido en 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:
// validation
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
}
} //if
// se devuelve 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. Al haber errores, el controlador devolvió al cliente la vista asociada al atributo input. Para averiguar 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"
/>
Por lo tanto, 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> se limita a mostrar la lista de mensajes que le ha enviado el controlador Struts. Utiliza el archivo de mensajes indicado por la etiqueta <message-resources>:
En él se encuentran las siguientes claves y mensajes:
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
Utilicemos 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 ha utilizado 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
Rellenamos el siguiente formulario y luego utilizamos 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] anterior. Obtenemos la siguiente página:
Observamos que el formulario aparece tal y como lo validamos.
Explicaciones: son las mismas que las de 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 ha rellenado el formulario y lo ha enviado al servidor
- en el segundo, el usuario ha utilizado el enlace [Retour au formulaire] para volver al formulario.
La única forma de que, en el segundo intercambio, 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 recuperado sus valores en el segundo intercambio.
3.3.6. Prueba 6
Volvamos al formulario para introducir esta vez datos válidos:
Validemos 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 retorno al controlador Struts del resultado ActionErrors del método validate de FormulaireBean. 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, que debe devolver un objeto de tipo ActionForward indicando la vista que el controlador debe enviar como respuesta al cliente. Aquí, el atributo type designa la clase predefinida ForwardAction. El método execute de esta clase no hace nada y se limita a devolver un objeto ActionForward que apunta a la vista definida por el atributo parameter, en este caso la vista /vues/main.html. Esta es, efectivamente, la vista que el controlador ha devuelto.
3.3.7. Prueba 7
Volvemos a solicitar la vista /formulaire.do:
Encontramos el formulario tal y como lo hemos validado. La explicación ya se ha dado. Mediante la configuración (scope="session") hemos solicitado que el formulario permanezca en la sesión. Por lo tanto, sus valores se conservan a lo largo de los intercambios cliente-servidor.
Ya casi hemos terminado. Nos queda crear una acción real para el caso de 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 struts-config.xml actual, salvo para modificar 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 hace referencia 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 tenía que hacer y devolvía un objeto de tipo ActionForward que indicaba la vista que el controlador debía devolver al cliente. A menudo hay varias vistas posibles en función del resultado del procesamiento del formulario. La lista de las diferentes vistas posibles se incluye en las etiquetas <forward> contenidas dentro de la etiqueta <action>. La sintaxis de dicha etiqueta es la siguiente:
cualquier nombre que identifique una vista de forma única | |
URL de la vista asociada a la clave |
3.5. La clase FormulaireAction
Escribir la clase FormulaireAction consiste básicamente 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");
}//execute
}
El método execute recibe cuatro parámetros:
- ActionMapping mapping: un objeto «imagen» de la configuración de la acción que se está ejecutando, por lo que en este caso se trata de 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 este modo, la acción tiene acceso a las claves asociadas a las vistas que 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 este modo, 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 dispone de todos los parámetros de la solicitud inicial (request.getParameter), así como de todos los atributos añadidos a dicha solicitud inicial (request.getAttribute). En nuestro ejemplo, el método execute enriquece la solicitud añadiendo 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 devuelve un ActionForward con «respuesta» como clave para indicar que debe enviarse 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 /vues/reponse.personne.jsp:
<%
// se recuperan los datos de nombre y 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 rellenamos:
Utilizamos el botón [Envoyer] y obtenemos la siguiente respuesta:
Explicaciones:
- retomaremos la explicación dada para la prueba n.º 2 para el inicio del proceso. 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 ha creado o reciclado un objeto frmPersonne de tipo FormulaireBean y ha introducido en él los valores del formulario
- Se ha llamado al método validate del objeto frmPersonne. Al ser los datos válidos, el método validate ha devuelto una lista ActionErrors vacía.
- Se ha creado o reciclado un objeto FormulaireAction y se ha llamado a su método execute. Este ha devuelto 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, /vues/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 crear esta aplicación sin Struts, utilizando un servlet y páginas JSP. Para un principiante, probablemente sea así. Con la experiencia, resulta 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 simplifica porque tienen una arquitectura estándar.