3. Processamento do formulário pelo controlador
Vamos agora centrar-nos no processamento dos valores do formulário pelo controlador quando o utilizador clicar no botão [Envoyer] do formulário.
3.1. O ficheiro struts-config.xml
O novo ficheiro de configuração struts-config.xml do controlador Struts passa a ser o seguinte:
<?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>
Destacámos as alterações:
- surge uma secção <form-beans>. Esta serve para definir as classes associadas a cada um dos formulários da aplicação. Deve haver tantas etiquetas <form-bean> quantos forem os formulários diferentes na aplicação. Aqui, temos apenas um formulário, pelo que existe apenas uma secção <form-bean>. Para cada formulário, temos de definir:
- o seu nome (atributo name)
- o nome da classe derivada de ActionForm responsável por armazenar os valores do formulário (atributo type)
Estes dois atributos não podem ser quaisquer. Têm de ser idênticos aos utilizados na baliza <html:form> do código HTML do formulário. Recorde-se que, para o formulário (nome, idade), estes são:
O formulário deve ser declarado da mesma forma no ficheiro struts-config.html. É isso que se faz aqui:
- A configuração da ação /main foi alterada. Esta ação é responsável por processar os valores do formulário. Por isso, é necessário fornecer-lhe as informações de que necessita no formulário:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
O servlet /main irá processar um formulário ao qual é necessário atribuir um nome. É o atributo name que desempenha essa função. Este nome deve referenciar o atributo name de uma das secções <form-bean>, neste caso frmPersonne.
O atributo scope="session" indica que os valores do formulário devem ser armazenados na sessão. Isto nem sempre é necessário. Neste caso, é. Com efeito, nas vistas /reponse.do e /erreurs.do, encontramos links que remetem para o formulário. Em ambos os casos, pretendemos apresentar o formulário com os valores introduzidos pelo utilizador durante uma troca anterior entre cliente e servidor. Daí a necessidade de armazenar o formulário na sessão.
O atributo «validate» indica se o método «validate» do objeto frmPersonne deve ou não ser chamado. Este método serve para verificar a validade dos dados do formulário. Aqui, indicamos que os dados devem ser verificados, o que implica que teremos de escrever um método «validate» na classe FormulaireBean. O método validate do formulário é chamado pelo controlador Struts antes de o servlet /main ser chamado. Este método devolve como resultado um objeto do tipo ActionErrors, que é análogo a uma lista de erros. Se essa lista existir e não estiver vazia, o controlador Struts irá parar aí e enviará como resposta a vista indicada pelo atributo **input. A vista receberá na solicitação a lista ActionErrors, que poderá exibir com a tag <html:errors>. Acima, indicamos que, em caso de erros, o servlet /main deve enviar a vista /erreurs.do. Recorde-se que esta vista está associada à seguinte 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>
A vista utiliza corretamente a baliza <html:errors>, que permitirá apresentar a lista de erros. Nesta lista de erros, não se encontram mensagens de erro, mas sim identificadores de mensagens presentes no ficheiro referenciado pela baliza <message-resources> (atenção: «resources» com um único «s»):
A baliza abaixo indica que o ficheiro que contém as mensagens utilizadas pela aplicação se encontra no ficheiro WEB-INF/classes/ressources/personneressources.properties:
O que se encontra neste ficheiro? Trata-se de um ficheiro de propriedades correspondente à classe Properties do Java, ou seja, um conjunto de linhas do tipo chave=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 ficheiro de mensagens tem, pelo menos, duas funções:
- permite alterar as mensagens da aplicação sem ter de a recompilar
- permite a internacionalização das aplicações Struts. É possível criar vários ficheiros de recursos, um por idioma. O Struts utilizará automaticamente o ficheiro de mensagens correto, desde que sejam respeitadas determinadas normas na nomenclatura desses ficheiros.
- Se o método `validate` do formulário devolver uma lista de erros vazia, então o controlador Struts chama o método `execute` do servlet ForwardAction. É importante compreender aqui que, quando o método `execute` do servlet é executado, isso significa que os dados do formulário foram considerados válidos (desde que, claro, tenham sido verificados por `validate="true"`). É no método `execute` do servlet associado à ação que o programador processa efetivamente o formulário. É aí que se encontra o cerne do processamento (lógica de aplicação, utilização de classes de negócio e de classes de acesso aos dados). Por fim, o método devolve um resultado do tipo ActionForward, que indica ao construtor qual a vista que deve ser enviada como resposta ao cliente. Aqui, utilizámos a ação predefinida ForwardAction do Struts. O seu método `execute` limita-se a devolver um ActionForward que aponta para o URL indicado pelo atributo `parameter`:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Portanto, se os dados do formulário forem válidos, a ação /main irá devolver a vista /vues/main.html que já utilizámos.
3.2. A nova classe FormulaireBean
Já criámos uma primeira versão da classe FormulaireBean, responsável por armazenar os dados (nome, idade) do formulário formulaire.personne.jsp. Essa versão não verificava a validade dos dados. Agora, temos de o fazer, uma vez que indicámos no ficheiro struts-config.xml que os dados do formulário deviam ser verificados (validate="true") antes de serem transmitidos ao servlet ForwardAction. O código da classe passa a ser o seguinte:
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;
}
// idade
private String age = null;
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
// validação
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestão de erros
ActionErrors erreurs = new ActionErrors();
// o nome não pode estar vazio
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// a idade deve ser um número inteiro positivo
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// a idade deve ser um número inteiro positivo
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// apresenta-se a lista de erros
}
} //se
// retorna a lista de erros
return erreurs;
}
}
A novidade reside na implementação do método validate**. Este é chamado pelo controlador Struts depois de este ter atribuído aos atributos nom e age da classe os valores dos campos do formulário com os mesmos nomes. Deve verificar a validade dos atributos nom e age**. O código acima é bastante simples de compreender:
- é criada uma lista de erros (ActionErrors erros) vazia
- o campo «nome» é verificado. Se estiver vazio, é adicionado um erro à lista de erros através do método ActionErrors.add("chave", ActionError).
- Faz-se o mesmo se o campo «idade» não for um número inteiro.
- O método validate devolve ao controlador Struts a lista de erros (ActionErrors erros). Se erros for igual a null ou se erreurs.size() for igual a 0, o controlador considera que não ocorreram erros. Nesse caso, executará o método `execute` da classe `Action` associada à ação (type="org.apache.struts.actions.ForwardAction"). Caso contrário, devolverá a vista associada ao caso de erros no formulário (input="/erreurs.do").
Adiciona-se um erro à lista ActionErrors erros por ActionErrors.add("cléErreur", new ActionError("cléMessage"[,param0, param1, param2, param3])). O primeiro parâmetro «cléErreur» serve para identificar de forma única um elemento ActionError na lista ActionErrors, tal como num dicionário. Pode ser qualquer valor. ActionError é um objeto que se associa a uma mensagem de erro através do seu construtor ActionError(String cléMessage[,String param0, String param1, String param2, String param3]), em que cléMessage é o identificador da mensagem associada ao erro e pode incluir até 4 parâmetros opcionais. O identificador cléMessage não é qualquer um. É um dos identificadores que se encontram no ficheiro indicado pela baliza <message-resources> do ficheiro struts-config.xml:
Recorde-se que este ficheiro (na realidade, WEB-INF/classes/ressources/personneressources.properties) contém as seguintes chaves:
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>
É possível verificar que as chaves de mensagens utilizadas pelo método validate da classe FormulaireBean existem efetivamente no ficheiro acima referido. Utilizou-se a baliza HTML <li> para cada mensagem de erro, para que a baliza <html:errors> as exiba como uma lista HTML. Vimos que o objeto ActionError pode ser construído não só com uma chave de mensagem, mas também com parâmetros adicionais:
Se um ActionError tiver sido construído com parâmetros adicionais (até um máximo de quatro), estes ficam acessíveis no texto da mensagem através da notação {0} a {3}. Assim, o método «validate» de FormulaireBean cria um ActionError com a chave personne.formulaire.age.incorrect e o parâmetro adicional «param0 age»:
A mensagem associada, no ficheiro .properties das mensagens, à chave personne.formulaire.age.incorrect é
O {0} será substituído pelo valor da idade. Por fim, as mensagens com as chaves errors.header e errors.footer serão escritas, respetivamente, antes e depois da lista de erros. Aqui, estas duas chaves servirão para incluir as balizas HTML <ul> e </ul>, que devem envolver as balizas <li>.
3.3. Testes de validade do formulário
Estamos prontos para os testes de validade do formulário. Recordamos abaixo onde devem ser colocados os diferentes componentes da aplicação:
 | |
 | |
 | |
 |
3.3.1. Teste 1
Vamos reiniciar o Tomcat para que leia os novos ficheiros de configuração e, em seguida, solicitemos o URL http://localhost:8080/strutspersonne/formulaire.do:
Explicações:
- no struts-config.html, foi explorada a seguinte secção:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Se analisarmos o código HTML da página recebida, verificamos que a tag <form> da página é a seguinte:
O botão [Envoyer], que é do tipo «submit», enviará, portanto, os dados do formulário para URL /strutspersonne/main.do.
3.3.2. Teste 2
Utilizemos o botão [Envoyer], deixando os campos de preenchimento em branco. Obtemos a seguinte resposta:
Explicações:
- conforme indicado acima, os dados do formulário foram enviados para o URL /strutspersonne/main.do. Foram então utilizadas as seguintes secções do ficheiro 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"
/>
A ação /main foi acionada. Esta utiliza o formulário frmPersonne (name="frmPersonne"). O controlador Struts instanciou, portanto, se necessário, um objeto da classe FormulaireBean (type="istia.st.struts.personne.FormulaireBean" na tag form-bean). Preencheu os atributos «nome» e «idade» desse objeto com os campos com os mesmos nomes do formulário 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>
Feito isto, o controlador Struts chamou o método validate do objeto FormulaireBean, porque o atributo validate da ação **/main está definido como true** no ficheiro de configuração:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
O método «validate» da classe FormulaireBean é o seguinte:
// validação
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
// gestão de erros
ActionErrors erreurs = new ActionErrors();
// o nome não pode estar vazio
if (nom == null || nom.trim().equals("")) {
erreurs.add("nomvide", new ActionError("personne.formulaire.nom.vide"));
// a idade deve ser um número inteiro positivo
}
if (age == null || age.trim().equals("")) {
erreurs.add("agevide", new ActionError("personne.formulaire.age.vide"));
}
else {
// a idade deve ser um número inteiro positivo
if (!age.matches("^\\s*\\d+\\s*$")) {
erreurs.add("ageincorrect", new ActionError("personne.formulaire.age.incorrect", age));
// apresenta-se a lista de erros
}
} //se
// retorna-se a lista de erros
return erreurs;
}
Uma vez que os campos [nom] e [age] estavam vazios, o método validate acima gerou uma lista de dois erros que devolveu ao controlador Struts. Como havia erros, o controlador devolveu então ao cliente a vista associada ao atributo input. Para determinar de que vista se tratava, utilizou a seguinte secção do seu ficheiro de configuração:
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Por fim, enviou a vista /vistas/erreurs.personne.jsp. Esta tem o seguinte 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>
A baliza <html:errors> apresenta simplesmente a lista de mensagens que o controlador Struts lhe enviou. Utiliza o ficheiro de mensagens indicado pela baliza <message-resources>:
Nele encontram-se as seguintes chaves e mensagens:
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>
- a mensagem associada à chave errors.header é gravada
- as mensagens associadas às diferentes chaves da lista ActionErrors recebida são gravadas
- a mensagem associada à chave errors.footer é gravada
3.3.3. Teste 3
Utilizemos o link [Retour au formulaire] da página de erros. Obtemos a seguinte página:
Explicações:
- o link [Retour au formulaire] tem o seguinte código: HTML:
O controlador Struts utilizou a seguinte secção do seu ficheiro de configuração:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Assim, devolveu a vista /vistas/formulaire.personne.jsp.
3.3.4. Teste 4
Preenchemos o seguinte formulário e, em seguida, utilizamos o botão [Envoyer]:
Obtemos a seguinte resposta:
Explicações: são as mesmas do teste n.º 2.
3.3.5. Teste 5
Utilizamos o link [Retour au formulaire] acima. Obtemos a seguinte página:
Constatamos que o formulário se encontra no estado em que o validámos.
Explicações: são as do teste n.º 3, com uma informação adicional:
- o formulário HTML apresentado contém as seguintes balizas:
<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>
As etiquetas <html:text> têm duas funções:
- ao enviar os valores do formulário do cliente para o servidor, os valores dos campos de entrada do formulário são atribuídos aos campos com o mesmo nome do objeto FormulaireBean
- ao enviar o código HTML do formulário a apresentar do servidor para o cliente, os atributos «value» dos campos de entrada associados às balizas <html:text> são inicializados com os valores dos campos com o mesmo nome do objeto FormulaireBean.
Estamos aqui perante duas trocas cliente-servidor diferentes:
- no primeiro, o utilizador preencheu o formulário e enviou-o para o servidor
- no segundo, o utilizador utilizou o link [Retour au formulaire] para regressar ao formulário.
A única forma de, na segunda interação, o formulário poder ser exibido novamente com os seus valores originais é que estes sejam colocados na sessão do cliente. Foi isso que foi solicitado na secção que configura a ação /main:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
Se tivéssemos definido scope="request", os dados do formulário não teriam sido armazenados na sessão e, por isso, não teríamos recuperado os seus valores na segunda troca de dados.
3.3.6. Teste 6
Voltemos ao formulário para introduzir, desta vez, dados válidos:
Enviemos o formulário. Obtemos o seguinte resultado:
Explicações:
- uma vez que o botão [Envoyer] envia os valores do formulário para o URL /strutspersonne/main.do, encontramos as mesmas explicações que no teste n.º 2 até ao regresso ao controlador Struts do resultado ActionErrors do método validate de FormulaireBean. Mas, neste caso, esta lista está vazia. O controlador utiliza então uma nova parte da configuração da ação /main:
<action
path="/main"
name="frmPersonne"
scope="session"
validate="true"
input="/erreurs.do"
parameter="/vues/main.html"
type="org.apache.struts.actions.ForwardAction"
/>
O controlador Struts cria, se necessário, um objeto do tipo indicado pelo atributo type. O método execute desta classe é executado e deve devolver um objeto do tipo ActionForward, indicando a vista que o controlador deve enviar como resposta ao cliente. Aqui, o atributo type refere-se à classe predefinida ForwardAction. O método execute** desta classe não faz nada e limita-se a devolver um objeto **ActionForward que aponta para a vista definida pelo atributo parameter, neste caso a vista **/vues/main.html**. Esta é, de facto, a vista que o controlador devolveu.
3.3.7. Teste 7
Solicitamos novamente a vista /formulaire.do:
Encontramos o formulário tal como o validámos. A explicação já foi dada. Por configuração (scope="session"), solicitámos que o formulário permanecesse na sessão. Os seus valores são, portanto, conservados ao longo das trocas cliente-servidor.
Estamos quase a terminar. Resta-nos criar uma ação propriamente dita para o caso de os dados do formulário serem válidos. Por enquanto, utilizámos a ação predefinida ForwardAction para simplificar a nossa demonstração.
3.4. Nova configuração da ação /main
Não alteramos o ficheiro de configuração struts-config.xml atual, exceto para modificar a sua secção /main da seguinte forma:
<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>
O atributo «type» refere-se agora a outra classe chamada FormulaireAction, que teremos de criar. É o método «execute» desta classe que será executado se os dados do formulário frmPersonne forem válidos. Indicámos que o método **execute fazia o que tinha de fazer e devolvia um objeto do tipo **ActionForward, indicando a vista que o controlador deveria devolver ao cliente. Muitas vezes, existem várias vistas possíveis, dependendo do resultado do processamento do formulário. A lista das diferentes vistas possíveis é apresentada nas balizas <forward> incluídas na baliza <action>. A sintaxe dessa baliza é a seguinte:
qualquer nome que identifique uma vista de forma única | |
URL da vista associada à chave |
3.5. A classe FormulaireAction
Escrever a classe FormulaireAction consiste essencialmente em escrever o seu 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 {
// temos um formulário válido; caso contrário, não teríamos chegado até aqui
FormulaireBean formulaire=(FormulaireBean)form;
request.setAttribute("nom",formulaire.getNom());
request.setAttribute("age",formulaire.getAge());
return mapping.findForward("reponse");
}//executar
}
O método «execute» recebe quatro parâmetros:
- Mapeamento ActionMapping: um objeto «imagem» da configuração da ação em execução; neste caso, uma imagem da seguinte configuração:
<action
path="/main"
name="frmPersonne"
validate="true"
input="/erreurs.do"
type="istia.st.struts.personne.FormulaireAction"
>
<forward name="reponse" path="/reponse.do"/>
</action>
Desta forma, a ação tem acesso às chaves associadas às vistas, que podem ser devolvidas ao cliente no final da ação. O método executado deverá devolver uma dessas chaves.
- ActionForm form: o objeto bean no qual se encontram os valores do formulário utilizado pela ação em curso. Neste caso, trata-se do objeto frmPersonne do tipo FormulaireBean. Assim, a ação tem acesso aos valores do formulário.
- HttpServletRequest request: o pedido do cliente que pode ter sido enriquecido por diferentes servlets. A ação tem, assim, acesso a todos os parâmetros do pedido inicial (request.getParameter), bem como a todos os atributos adicionados a esse pedido inicial (request.getAttribute). No nosso exemplo, o método `execute` enriquece a solicitação, adicionando-lhe o nome e a idade. Isto é totalmente desnecessário aqui, uma vez que estes dois valores já se encontram na solicitação, mas como parâmetros e não como atributos. O código está aqui apenas a título de exemplo.
- Resposta HttpServletResponse: a resposta que será enviada ao cliente. A ação poderia enriquecer esta resposta. Aqui, não o faz.
Aqui, estamos perante um caso específico. O método **execute quase não tem nada para fazer. Deve simplesmente indicar que a vista seguinte é a vista **/reponse.do e especificar na requisição que essa vista receberá as informações «nome» e «idade» que deve apresentar. Faz-o através do método findForward da classe ActionMapping, que aceita como parâmetro uma das chaves encontradas nas balizas «forward» da configuração da ação. Aqui, existe apenas uma baliza desse tipo:
O nosso método executa, portanto, um ActionForward com «resposta» como chave para indicar que a vista /reponse.do deve ser enviada.
3.6. Testes do FormulaireAction
Compilamos a classe anterior com o JBuilder e colocamos o ficheiro .class gerado em WEB-INF/classes:
Alteramos a vista /vues/reponse.personne.jsp:
<%
// recuperam-se os dados nome e idade
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>
A vista recupera as informações «nome» e «idade» nos atributos do pedido que recebe. Solicitamos o formulário ao URL http://localhost:8080/strutspersonne/formulaire.do e, em seguida, preenchemo-lo:
Utilizamos o botão [Envoyer] e obtemos a seguinte resposta:
Explicações:
- Vamos retomar a explicação dada para o teste n.º 2 no início do processo. Recorde-se a configuração da ação /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>
- Após o envio do formulário ao controlador no URL /main.do, este criou ou reutilizou um objeto frmPersonne do tipo FormulaireBean e inseriu nele os valores do formulário
- foi chamado o método validate do objeto frmPersonne. Como os dados eram válidos, o método validate devolveu uma lista ActionErrors vazia.
- Foi criado ou reciclado um objeto FormulaireAction e o seu método `execute` foi chamado. Este devolveu um objeto ActionForward com a chave «resposta».
- O controlador enviou então a vista associada à chave «resposta», c.a.d. /reponse.do e, consequentemente, /vues/reponse.personne.jsp.
- A vista reponse.personne.jsp foi apresentada com os valores inseridos na solicitação pelo método execute do objeto FormulaireAction.
3.7. Conclusão
Construímos uma aplicação completa, mas simples. Ao implementá-la efetivamente com Struts, Tomcat e JBuilder, surgem inúmeras oportunidades para cometer erros, nomeadamente nos ficheiros de configuração da aplicação, como o XML. À primeira vista, pode parecer mais simples construir esta aplicação sem o Struts, utilizando um servlet e páginas JSP. Para um principiante, isso é provavelmente verdade. À medida que se ganha experiência, torna-se mais simples desenvolver com o Struts. Muitas empresas impõem a metodologia Struts para os seus desenvolvimentos web pelas seguintes razões:
- O Struts respeita o modelo MVC
- quando todos os programadores trabalham da mesma forma, a manutenção das aplicações torna-se mais simples, uma vez que estas têm uma arquitetura padrão.