Struts: Dominando Tiles e DynaForms – Parte 03

Aprofundando o conhecimento

Vimos até aqui um pouco da funcionalidade dos tiles e você pode estar se perguntando: “qual a vantagem que eu tenho usando-os?”. Como dissemos no início, eles são usados para definir templates. O tile que acabamos de definir (Listagem 4) nos servirá como base (template) para os outros arquivos JSP, referentes à aplicação de exemplo que iremos criar. Esta aplicação será um simples formulário de login que nos redirecionará a uma tela de boas-vindas.

Devemos definir um novo arquivo ao qual daremos o nome de helloWorld.jsp. Para isso criamos um arquivo conforme a Listagem 5.


net-17-04-2008pic02.JPG 

Listagem 5. Simples página JSP com tagLibs.

 

Não se preocupe com a taglib utilizada acima, mais a frente entenderemos o uso dela. Um padrão interessante a adotar, agora que conhecemos os tiles, é o de nunca definir um forward de uma action do struts diretamente para um arquivo JSP, mas sempre para um tile (ver Listagem 6), pois garantimos assim a centralização das informações referentes às páginas JSP e uma fácil manutenção posterior.


net-17-04-2008pic03.JPG

Listagem 6. Action retornando seu forward para um tile.

 

Definimos, nessa action, que ela tem sua origem de uma tile.login através do atributo input. E dissemos que quando o forward for success, a página será redirecionada para tile.welcome. Entretanto, se um dia quiséssemos que nosso forward fosse feito, por exemplo, para uma página de “Em Construção”, apenas teríamos que mudar nosso “tile.welcome” sem precisarmos nos preocupar com quais actions o utilizam e nem mesmo mexer em código Java. Na Listagem 7 temos a nossa classe action, de login.

 

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

 

import org.apache.struts.action.Action;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

import org.apache.struts.action.DynaActionForm;

 

public class LoginAction extends Action

{

  public ActionForward execute(ActionMapping mapping,

                               ActionForm form,

                               HttpServletRequest request,

                               HttpServletResponse response

                              ){

    return mapping.findForward("success");

  }

}

Listagem 7. Classe action de login que será usada em nossa aplicação.

 

Na Listagem 8 temos a definição dos tiles usados para o exemplo da Listagem 5. Insira esses dois novos tiles no arquivo tiles-defs.xml. Cada definition deve ser colocada entre as marcações já existentes em nosso arquivo, ....

net-17-04-2008pic04.JPG
Listagem 8.
Declaração de novos tiles.

Essa sim é a grande vantagem que temos em usar tiles. Podemos, somente mudando nosso xml, mudar todo o “andamento” da aplicação. Vamos usar nossa action definida na Listagem 5 como exemplo. Nesta action, definimos que quando um forward success for requisitado, então nossa aplicação será redirecionada para o tile.welcome. No entanto, não sabemos exatamente para onde o tile.welcome está apontando, ou seja, se agora quisermos que o tile.welcome aponte para listaUsuarios.jsp, basta mudarmos o valor de nosso tile e nada mais. Isso faz com que haja uma transparência e um grande ganho no desenvolvimento e na manutenção de nossas aplicações.

Na Figura 2 temos a demonstração de como ficará nossa página final, depois de configurados nossos tiles e após vermos a próxima seção desse artigo que são os DynaForms. O quadro em vermelho é o nosso header, o quadro em azul é o nosso application e o quadro em verde é o nosso footer.

 

net-17-04-2008pic01.JPG 

Figura 2. Página final de nossa aplicação.

 

A nossa primeira definition (Listagem 8, linha 1) nos diz que sempre que o tile.login for referenciado ou chamado explicitamente, a página chamada será a declarada no atributo path (/pages/login.jsp).

Em nossa segunda definição, dizemos que o tile.welcome herda (extends) de tile.mainLayout (linha 3). Isso mesmo! Pode-se fazer uma definição estender de outra, para que haja reutilização e padronização de nosso código. As heranças de definições podem ser feitas indefinidamente, ou seja, é possível se ter uma hierarquia grande de definições.

Assim como em classes java, quando herdamos tiles adquirimos suas características e funcionalidades. E ainda em analogia a classes java, podemos sobrescrever funcionalidades predefinidas, que é o que acontece em nossa definição (Listagem 8, linha 4). Fazendo essa herança, garantimos que todas as funcionalidades do tile herdado serão adicionadas à nova definição (tile) e assim economizamos tempo, esforço, evitamos erros tanto por replicar código quanto na manutenção posterior fazendo com que a manutenção tenha que ser dada somente em um arquivo, ou poucos arquivos.

Além da extensão, dizemos que o atributo “application” do tile.mainLayout receberá a página definida dentro da tag put dessa nossa definição. Ou seja, cada chamada para tile.welcome, fará uma chamada para tile.mainLayout, e definirá o atributo application como a página helloWorld.jsp.

Isso nos garante uma grande facilidade no desenvolvimento após a definição de toda a arquitetura, e nos permite que uma aplicação seja reconfigurada muito facilmente, com uma simples configuração de poucos arquivos. O que nos tomaria horas, senão dias, caso usássemos definições diretas para páginas JSP nas actions, ou pior, caso usássemos nossos antigos