Artigo Java Magazine 34 - Melhores Práticas para o Struts

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo Publicado pela Java Magazine 34.

Esse artigo faz parte da revista Java Magazine edição 34. Clique aqui para ler todos os artigos desta edição

jm34.jpg

 

Melhores Práticas para o Struts

Maximize o Aproveitamento do Mais Popular Framework Web

Como melhorar a gerenciabilidade de aplicações Struts, a reutilização de componentes da aplicação e usufruir dos recursos fornecidos por outros padrões como o JSTL

Fernando Lozano

O Struts é talvez o framework Java de maior sucesso em toda a história, e certamente o mais popular dentre os frameworks para desenvolvimento web. Mas em seis anos de vida (desde a sua primeira versão) tanto o próprio Struts quando o Java EE evoluíram, e muitos desenvolvedores ainda trabalham da forma como aprenderam originalmente com o Struts 1.0 ou 1.1.

O objetivo deste artigo é orientar tanto iniciantes, que estão começando o seu aprendizado do Struts, quanto profissionais mais experientes, que podem usar o que mostramos aqui para explorar novas possibilidades em versões recentes do Struts. Primeiro serão discutidas recomendações sobre como fazer o melhor uso do Struts, e depois será apresentado um substituto para o struts-blank, a aplicação-modelo fornecida com o framework. Essa aplicação é modificada de acordo com as recomendações expressas neste artigo, e inclui alguns exemplos de formulários, ações e validadores, que o struts-blank original não fornece.

Neste artigo, ao contrário da maior parte da documentação do Struts, não se teve a preocupação em manter a compatibilidade com versões mais antigas das especificações de Servlets e JSP. As práticas e exemplos apresentados esperam um container web moderno, que suporte ao menos Servlets 2.4 e JSP 2.0. O exemplo foi testado com o Tomcat 5.x, mas deverá funcionar sem modificações em outros containers que implementem as versões mais recentes das especificações.

O Struts foi tratado de forma geral em vários artigos da Java Magazine, como "Struts Essencial", na Edição 6, "Struts vai às compras" (Edição 11), "Views com Struts" (Edição 19) e "Struts Multipáginas" (Edição 20). A validação com o Struts Validator foi discutida na Edição 7 e recentemente na Edição 31.

1. Estruture os arquivos de configuração de acordo com a aplicação

Todos nós iniciamos o uso do Struts com algum tutorial que explica o uso do arquivo struts-config.xml, e a maioria aprende logo também a usar também o validation.xml. A idéia adotada no Struts, de definir regras de navegação e validação de forma declarativa em arquivos XML, em vez de fazê-lo de forma procedural em código Java, aumenta a produtividade do desenvolvedor e facilita futuras mudanças no fluxo de páginas de uma aplicação web.

Mas um problema é que podemos nos esquecer que estes arquivos XML são parte integrante da lógica da aplicação. Os mesmos fatores afetam a facilidade de manutenção de código Java também afetam a manutenibilidade de lógica expressa em XML ou em qualquer outra linguagem. Alguém criaria um único método Java contendo 500 linhas de código? Então porque os arquivos de configuração do Struts[1] deveriam crescer tanto sem que nenhum desenvolvedor reclame?

O fato é que em aplicações reais a quantidade de ações e formulários, ou seja, de possibilidades de interação do usuário com a aplicação, pode tornar os arquivos de configuração quase impossíveis de gerenciar. Usar uma ferramenta de apoio, como o plug-in Struts Console para o Eclipse, ou o editor de arquivos de configuração de outros IDEs, apenas “adia” um pouco o ponto onde a alteração do struts-config.xml e do validation.xml se torna um peso considerável sobre os desenvolvedores

Mas não é necessário colocar tudo em apenas dois arquivos, um para os Actions e outro para o Validator! Os nomes “struts-config.xml” e “validation.xml” são nomes fornecidos pelo próprio  desenvolvedor em outros arquivos de configuração. Além de ser possível usar outros nomes, pode ser configurada uma lista de arquivos, em vez de um único arquivo. O Struts e o Validator usarão sem problemas todos os arquivos listados, sem impor nenhuma restrição sobre o que pode ser definido em cada um deles.

Em vez dois únicos arquivos já citados, pode ser criado um conjunto de arquivos de configuração “globais” e conjuntos de arquivos de configuração para cada módulo ou subsistema importante da sua aplicação. Por exemplo, em um site de vendas on-line, com um módulo de catálogo de produtos e outro módulo para efetivação de compras, a estrutura de arquivos de configuração ficaria assim:

?         WEB-INF

      web.xml (mapeia o ActionServlet e relaciona os arquivos de configuração struts-xxx.xml)

      struts-global.xml (define exceções e forwarders globais, além de arquivos de configuração dos validadores)

      validator-rules.xml (validadores embutidos no struts)

      validator-custom.xml (validadores acrescentados pela aplicação)

      catalogo

¦        actions.xml (Actions e formulários para o módulo de catálogo de produtos)

¦        validation.xml (validações para o módulo de catálogo de produtos)

      compras

¦        actions.xml (Actions e formulários para o módulo de check-out das compras e consulta ao carrinho)

¦        validation.xml (validações para o módulo de check-out das compras e consulta ao carrinho)

 

A idéia é criar diretórios adicionais sob a pasta WEB-INF para agrupar todos os arquivos de configuração relacionados com um mesmo módulo ou subsistema da aplicação. (O exemplo disponível para download contém apenas um módulo, chamado “agenda”, seguindo a mesma convenção de nomes apresentada.)

A Listagem 1 apresenta exemplos de como configurar esta situação, fornecendo trechos de código para os arquivos web.xml e struts-global.xml. Observe que não foram utilizados os nomes default struts-config.xml e validation.xml. Assim lembramos aos desenvolvedores de procurarem o arquivo correto, sempre que forem acrescentar uma nova definição de Action, formulário ou validação.

O arquivo validator-custom.xml, serve para a definição de validadores não-padrão (ou sejam, que não sejam fornecidos pelo próprio Validator). Esse arquivo poderia ser quebrado de modo a facilitar a reutilização de grupos de validadores customizados por outras aplicações. Por exemplo, validator-documentos.xml poderia fazer a validação de RGs, CPFs, Inscrições Estaduais e de outros números e códigos que representam documentos oficiais. Já validator-telefones.xml poderia conter validadores para números telefônicos com ou sem código de operadora ou DDD. Nesse caso, pode ser interessante criar um subdiretório separado apenas para as definições de validadores não-padrão.

A mesma idéia de organizar arquivos de configuração de acordo com a estrutura lógica da aplicação também vale para arquivos de mensagens (para internacionalização), e arquivos de configuração do Tiles e de outros componentes utilizados pela aplicação.

Se os arquivos de mensagens forem segmentados, será necessário definir uma “chave” (key) para cada um. Esta chave será referenciada nos tags html do Struts: ou no Validator pelo atributo bundle.

2. Use o JSTL e o EL do JSP 2.0 em vez dos taglibs Logic e Bean

Quando o Struts surgiu, não havia ainda um conjunto de tags padronizados para desenvolvimento JSP. Então foram criados dentro do Struts vários taglibs cumprindo a funcionalidade hoje coberta pelo JSTL, a saber: logic, bean, html e nested.

Os tags logic permitem executar dentro da página JSP operações de decisão e repetição; já os tags bean e nested servem permitir a manipulação de objetos Java armazenados na requisição ou na sessão. Nos dois casos, o objetivo era evitar o uso direto de código Java (scriptlets) nas páginas JSP. Este objetivo foi o mesmo que norteou o JCP a definir o JSTL, e a Expression Language (EL) que foi incorporada ao JSP 2.0.

Os próprios desenvolvedores do Struts recomendam o uso do JSTL e do EL do JSP 2.0, em vez das taglibs do Struts, por serem tecnologias padronizadas do Java EE e serem na maioria dos casos mais poderosas e práticas do que os tags do próprio Struts. Na maioria dos casos, o código escrito com JSTL e a EL é mais compacto e mais flexível do que o equivalente usando com taglibs do Struts. As taglibs originais são mantidas, na maior parte, apenas para manter a compatibilidade retroativa com aplicações desenvolvidas para versões antigas do Struts, ou que ainda têm que rodar em containers web que suportam apenas o JSP 1.1 ou 1.2.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?