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

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)

ATENÇÃO! A exibição deste artigo foi interrompida.

  #Este é um post fechado

Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!