3. Processamento do formulário pelo controlador
Vamos nos concentrar agora no processamento dos valores do formulário pelo controlador quando o usuário clicar no botão [Envoyer] do formulário.
3.1. O arquivo struts-config.xml
O novo arquivo de configuração struts-config.xml do controlador Struts fica da seguinte forma:
<?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>
Destacamos as alterações:
- aparece uma seção <form-beans>. Ela serve para definir as classes associadas a cada um dos formulários do aplicativo. Deve haver tantas tags <form-bean> quanto formulários diferentes no aplicativo. Aqui, temos apenas um formulário, portanto, uma única seção <form-bean>. Para cada formulário, devemos definir:
- seu nome (atributo name)
- o nome da classe derivada de ActionForm responsável por armazenar os valores do formulário (atributo type)
Esses dois atributos não podem ser quaisquer. Eles devem ser idênticos aos utilizados na tag <html:form> do código HTML do formulário. Lembramos que, para o formulário (nome, idade), ela é:
O formulário deve ser declarado da mesma forma no arquivo struts-config.html. É isso que é feito aqui:
- A configuração da ação /main foi alterada. Ela é responsável por processar os valores do formulário. Portanto, é preciso fornecer as informações necessárias a ela 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 processará um formulário ao qual é necessário atribuir um nome. Esse trabalho é feito pelo atributo name. Esse nome deve fazer referência ao atributo name de uma das seções <form-bean>, neste caso, frmPersonne.
O atributo scope="session" indica que os valores do formulário devem ser armazenados na sessão. Isso nem sempre é necessário. Neste caso, porém, é. De fato, nas visualizações /reponse.do e /erreurs.do, encontramos links que remetem ao formulário. Em ambos os casos, queremos exibir o formulário com os valores inseridos pelo usuário 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. Esse 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 que escrever um método validate na classe **FormulaireBean**. O método validate do formulário é chamado pelo controlador Struts antes que o servlet /main seja chamado. Ele retorna 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 interromperá a execução nesse ponto e enviará como resposta a visualização indicada pelo atributo **input. A visualização receberá na solicitação a lista ActionErrors, que poderá ser exibida com a tag <html:errors>. Acima, afirmamos que, em caso de erros, o servlet /main deve enviar a visualização /erreurs.do. Vale lembrar que essa 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 visualização utiliza corretamente a tag <html:errors>, que permitirá exibir a lista de erros. Nessa lista de erros, não encontramos mensagens de erro, mas identificadores de mensagens presentes no arquivo referenciado pela tag <message-resources> (atenção: “resources” com um único “s”):
A tag abaixo indica que o arquivo contendo as mensagens utilizadas pelo aplicativo está localizado no arquivo WEB-INF/classes/ressources/personneressources.properties:
O que há nesse arquivo? Trata-se de um arquivo 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 arquivo de mensagens tem pelo menos duas funções:
- permite alterar as mensagens do aplicativo sem precisar recompilá-lo
- permite a internacionalização das aplicações Struts. É possível, de fato, criar vários arquivos de recursos, um por idioma. O Struts utilizará automaticamente o arquivo de mensagens correto, desde que sejam respeitadas certas normas na nomenclatura desses arquivos.
- Se o método `validate` do formulário retornar uma lista de erros vazia, o controlador Struts chamará o método `execute` do servlet ForwardAction. É importante entender 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 desenvolvedor realmente processa o formulário. É aí que se encontra o núcleo do processamento (lógica de aplicação, uso de classes de negócio e de classes de acesso a dados). Por fim, o método retorna um resultado do tipo ActionForward, que indica ao construtor qual visualização deve ser enviada como resposta ao cliente. Aqui, utilizamos a ação predefinida ForwardAction do Struts. Seu método `execute` limita-se a retornar 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 retornará a visualização /vues/main.html, que já utilizamos anteriormente.
3.2. A nova classe FormulaireBean
Já criamos 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, precisamos fazer isso, pois indicamos no arquivo struts-config.xml que os dados do formulário deveriam ser verificados (validate="true") antes de serem transmitidos para o servlet ForwardAction. O código da classe fica assim:
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));
// retornamos a lista de erros
}
} //if
// retorna-se a lista de erros
return erreurs;
}
}
A novidade está na implementação do método validate**. Esse método é chamado pelo controlador Struts depois que este atribui aos atributos nom e age da classe os valores dos campos do formulário com os mesmos nomes. Ele deve verificar a validade dos atributos nom e age**. O código acima é bastante simples de entender:
- é criada uma lista de erros (ActionErrors erros) vazia
- o campo “nome” é verificado. Se estiver vazio, um erro é adicionado à lista de erros por meio 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 retorna 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 houve erros. Ele então executará o método `execute` da classe `Action` associada à ação (type="org.apache.struts.actions.ForwardAction"). Caso contrário, ele retornará a visualização associada ao caso de erros no formulário (input="/erreurs.do").
Adicionamos um erro à lista ActionErrors erros por meio de 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, de maneira semelhante a um dicionário. Ele pode ser qualquer valor. ActionError é um objeto que se associa a uma mensagem de erro por meio de 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 conter até 4 parâmetros opcionais. O identificador cléMessage não é qualquer um. É um dos identificadores encontrados no arquivo indicado pela tag <message-resources> do arquivo struts-config.xml:
Vale lembrar que esse arquivo (na verdade, 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 realmente existem no arquivo acima. Utilizamos a tag HTML <li> para cada mensagem de erro, de modo que a tag <html:errors> as exiba como uma lista HTML. Vimos que o objeto ActionError pode ser construído não apenas com uma chave de mensagem, mas também com parâmetros adicionais:
Se um ActionError tiver sido construído com parâmetros adicionais (até quatro, no máximo), esses parâmetros ficam acessíveis no texto da mensagem por meio da notação {0} a {3}. Assim, o método validate de FormulaireBean gera um ActionError com a chave personne.formulaire.age.incorrect e o parâmetro adicional param0, que tem o valor:
A mensagem associada, no arquivo .properties de 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 gravadas, respectivamente, antes e depois da lista de erros. Aqui, essas duas chaves servirão para incluir as tags HTML <ul> e </ul>, que devem envolver as tags <li>.
3.3. Testes de validade do formulário
Estamos prontos para os testes de validade do formulário. Lembramos a seguir onde devem ser colocados os diferentes componentes do aplicativo:
 | |
 | |
 | |
 |
3.3.1. Teste 1
Vamos reiniciar o Tomcat para que ele leia os novos arquivos de configuração e, em seguida, acessar o URL http://localhost:8080/strutspersonne/formulaire.do:
Explicações:
- no struts-config.html, a seguinte seção foi explorada:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Se analisarmos o código HTML da página recebida, vemos 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
Vamos usar 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. As seguintes seções do arquivo struts-config.xml foram então utilizadas:
<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. Ela utiliza o formulário frmPersonne (name="frmPersonne"). O controlador Struts, portanto, instanciou, se necessário, um objeto da classe FormulaireBean (type="istia.st.struts.personne.FormulaireBean" na tag form-bean). Ele preencheu os atributos nome e idade desse objeto com os campos de mesmo nome 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 isso, o controlador Struts chamou o método validate do objeto **FormulaireBean, pois o atributo validate da ação **/main está definido como true no arquivo 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));
// retorna a lista de erros
}
} //se
// retorna-se a lista de erros
return erreurs;
}
Como os campos [nom] e [age] estavam vazios, o método validate acima gerou uma lista com dois erros, que foi enviada de volta ao controlador Struts. Como havia erros, o controlador, por sua vez, enviou de volta ao cliente a visualização associada ao atributo input. Para identificar de qual visualização se tratava, ele utilizou a seguinte seção de seu arquivo de configuração:
<action
path="/erreurs"
parameter="/vues/erreurs.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Portanto, ele acabou enviando a visualização /vues/erreurs.personne.jsp. Ela possui 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 tag <html:errors> simplesmente exibe a lista de mensagens que o controlador Struts lhe enviou. Ela utiliza o arquivo de mensagens indicado pela tag <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
Vamos usar o link [Retour au formulaire] da página de erros. Obtemos a seguinte página:
Explicações:
- o link [Retour au formulaire] possui o código HTML a seguir:
O controlador Struts utilizou a seguinte seção de seu arquivo de configuração:
<action
path="/formulaire"
parameter="/vues/formulaire.personne.jsp"
type="org.apache.struts.actions.ForwardAction"
/>
Portanto, ele retornou a visualização /vues/formulaire.personne.jsp.
3.3.4. Teste 4
Preenchemos o seguinte formulário e, em seguida, clicamos no botão [Envoyer]:
Recebemos 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 aparece exatamente como o validamos.
Explicações: são as mesmas do teste nº 3, com uma informação adicional:
- o formulário HTML exibido possui as seguintes tags:
<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 tags <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, do servidor para o cliente, o código HTML do formulário a ser exibido, os atributos value dos campos de entrada associados às tags <html:text> são inicializados com os valores dos campos de mesmo nome do objeto FormulaireBean.
Estamos aqui diante de duas trocas cliente-servidor diferentes:
- no primeiro, o usuário preencheu o formulário e o enviou ao servidor
- no segundo, o usuário utilizou o link [Retour au formulaire] para retornar ao formulário.
A única maneira de, na segunda interação, o formulário ser exibido novamente com seus valores originais é que esses valores sejam armazenados na sessão do cliente. Foi isso que foi solicitado na seção de 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"
/>
Se tivéssemos definido scope="request", os dados do formulário não teriam sido armazenados na sessão e, portanto, não teríamos recuperado esses valores na segunda troca de dados.
3.3.6. Teste 6
Voltemos ao formulário para inserir, desta vez, dados válidos:
Vamos enviar o formulário. Obtemos o seguinte resultado:
Explicações:
- como o botão [Envoyer] envia os valores do formulário para o URL /strutspersonne/main.do, encontramos as mesmas explicações do teste nº 2 até o retorno ao controlador Struts do resultado ActionErrors do método validate de FormulaireBean. Mas, neste caso, essa 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 dessa classe é executado e deve retornar um objeto do tipo ActionForward, indicando a visualização que o controlador deve enviar como resposta ao cliente. Aqui, o atributo type designa a classe predefinida ForwardAction. O método execute** dessa classe não faz nada e se limita a retornar um objeto **ActionForward que aponta para a visualização definida pelo atributo parameter, neste caso, a visualização **/vues/main.html**. Essa é, de fato, a visualização que o controlador retornou.
3.3.7. Teste 7
Solicitamos novamente a visualização /formulaire.do:
Encontramos o formulário exatamente como o validamos. A explicação já foi dada. Por meio da configuração (scope="session"), solicitamos que o formulário permanecesse na sessão. Seus valores, portanto, são mantidos ao longo das trocas entre cliente e servidor.
Estamos quase terminando. Resta criar uma ação propriamente dita para o caso em que os dados do formulário forem válidos. Por enquanto, utilizamos a ação predefinida ForwardAction para simplificar nossa demonstração.
3.4. Nova configuração da ação /main
Não alteramos o arquivo de configuração struts-config.xml atual, exceto para modificar sua seção /main da seguinte maneira:
<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 agora aponta para outra classe chamada **FormulaireAction, que teremos que criar. É o método execute dessa classe que será executado se os dados do formulário **frmPersonne forem válidos. Indicamos que o método **execute fazia o que era necessário e retornava um objeto do tipo **ActionForward, indicando a visualização que o controlador deveria enviar ao cliente. Muitas vezes, há várias visualizações possíveis, dependendo do resultado do processamento do formulário. A lista das diferentes visualizações possíveis está definida nas tags <forward> incluídas na tag <action>. A sintaxe dessa tag é a seguinte:
qualquer nome que identifique uma visualização de forma única | |
URL da visualização associada à chave |
3.5. A classe FormulaireAction
Escrever a classe FormulaireAction consiste essencialmente em escrever 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; portanto, 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>
Assim, a ação tem acesso às chaves associadas às visualizações, que podem ser retornadas ao cliente ao final da ação. O método executado deverá retornar uma dessas chaves.
- ActionForm form: o objeto bean no qual se encontram os valores do formulário utilizado pela ação em andamento. Aqui, trata-se do objeto frmPersonne do tipo FormulaireBean. Assim, a ação tem acesso aos valores do formulário.
- HttpServletRequest request: a solicitação do cliente, que pode ter sido enriquecida por diferentes servlets. A ação tem, assim, acesso a todos os parâmetros da solicitação inicial (request.getParameter), bem como a todos os atributos adicionados a essa solicitação inicial (request.getAttribute). Em nosso exemplo, o método `execute` enriquece a solicitação adicionando o nome e a idade. Isso é totalmente desnecessário aqui, já que esses dois valores já estão presentes, 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 essa resposta. Aqui, ela não o faz.
Aqui, estamos diante de um caso específico. O método execute praticamente não tem nada a fazer. Ele deve simplesmente indicar que a próxima visualização é a visualização **/reponse.do e especificar na solicitação que essa visualização receberá as informações de nome e idade que deve exibir. Ela faz isso por meio do método findForward da classe ActionMapping, que aceita como parâmetro uma das chaves encontradas nas tags forward** da configuração da ação. Aqui, há apenas uma tag desse tipo:
Nosso método, ao ser executado, retorna, portanto, um ActionForward com “resposta” como chave para indicar que a visualização /reponse.do deve ser enviada.
3.6. Testes do FormulaireAction
Compilamos a classe anterior com o JBuilder e colocamos o arquivo .class gerado em WEB-INF/classes:
Modificamos a visualização /vues/reponse.personne.jsp:
<%
// recuperamos 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 visualização recupera as informações de nome e idade nos atributos da solicitação que recebe. Solicitamos o formulário ao URL http://localhost:8080/strutspersonne/formulaire.do e, em seguida, o preenchemos:
Utilizamos o botão [Envoyer] e obtemos a seguinte resposta:
Explicações:
- Retomaremos a explicação fornecida para o teste nº 2 no início do processo. Lembramos 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
- o método validate do objeto frmPersonne foi chamado. Como os dados eram válidos, o método validate retornou uma lista ActionErrors vazia.
- Um objeto FormulaireAction foi criado ou reciclado e seu método `execute` foi chamado. Este retornou um objeto ActionForward com a chave “resposta”.
- O controlador enviou então a visualização associada à chave “resposta”, c.a.d. /reponse.do e, portanto, /vues/reponse.personne.jsp.
- A visualização reponse.personne.jsp foi exibida com os valores inseridos na solicitação pelo método `execute` do objeto FormulaireAction.
3.7. Conclusão
Construímos uma aplicação completa, porém simples. Ao implementá-la de fato com Struts, Tomcat e JBuilder, há inúmeras oportunidades de cometer erros, principalmente nos arquivos de configuração da aplicação, como o XML. À primeira vista, pode parecer mais simples construir essa aplicação sem o Struts, utilizando um servlet e páginas JSP. Para o iniciante, isso provavelmente é verdade. Com o ganho de experiência, torna-se mais simples desenvolver com o Struts. Muitas empresas impõem a metodologia Struts para seus desenvolvimentos web pelas seguintes razões:
- O Struts segue o modelo MVC
- quando todos os desenvolvedores trabalham da mesma maneira, a manutenção das aplicações se torna mais simples, pois elas possuem uma arquitetura padrão.