gem_pdf.jpg src="/imagens/imagem_pdf.jpg" width=34 border=0>
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.
Projetos novos devem usar, além da JSTL, apenas as taglibs fornecidas pelo subprojeto Struts-EL. Esse subprojeto ...
