Visualizando o Struts: Detalhes do View com o Framework da Apache

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

Clique aqui para ler esse artigo em PDF.

Visualizando o Struts

Detalhes do View com o Framework da Apache

Aprenda a trabalhar com a parte mais visível das aplicações Struts: taglibs, ActionForms e DynaActionForms, validação e internacionalização

Entre as mais importantes e úteis funcionalidades do Struts estão a coleta e a validação de dados postados via formulários HTML, além do redirecionamento do processamento (que geralmente é baseado na verificação desses dados). Neste artigo, vamos falar sobre a camada View no Struts, o "V" da arquitetura MVC, abordando taglibs, mensagens, ActionForms, DynaActionForms, internacionalização e alternativas de validação.

Componentes do View

Em aplicações Struts, a camada View pode ser composta de páginas HTML, imagens e arquivos multimídia, páginas JSP (usando ou não taglibs do Struts), ActionForms, que recebem e disponibilizam os dados de formulário para processamento, e, indiretamente, de arquivos de propriedades, onde são configurados textos a serem exibidos pela aplicação. Na camada View podem também ser usados mecanismos de templates como o Tiles, que é parte do framework,  ou o Jakarta Velocity, entre outras técnicas e tecnologias. Aqui focaremos em páginas JSP e nas tecnologias oferecidas nativamente pelo Struts.

Taglibs do Struts

São fornecidas cinco bibliotecas com o Struts: HTML, com tags para criação de páginas dinâmicas e formulários; Beans para acesso a JavaBeans e suporte a internacionalização; Logic, com tags para loops e execução condicional; Tiles para a utilização do mecanismo de templates embutido; e Nested, para a manipulação de estruturas hierarquizadas de beans.Veja na Listagem 1 um exemplo de formulário utilizando algumas dessas taglibs. Observe no código a declaração das taglibs com a diretiva <%@ taglib uri="URI” prefix=”prefixo”> e a definição dos campos utilizando <html:tipo>. A Figura 1 mostra a tela resultante.

Nota: O uso de taglibs, tecnicamente, não é obrigatório nas páginas JSP de aplicações Struts, porém sua utilização facilita muito o desenvolvimento, permitindo tirar proveito dos recursos automáticos do framework, como preenchimento e validação de campos de formulário.

Prefira a JSTL

As bibliotecas de tags do Struts surgiram antes da padronização da JSTL (JSP Standard Tag Library). Várias têm praticamente as mesmas funcionalidades, e a recomendação é utilizar as tags equivalentes da JSTL no lugar das taglibs Logic e Bean do Struts. Veja na Listagem 2 um exemplo de página JSP com as tags Logic e na Listagem 3 o código equivalente usando a JSTL. A Figura 2 apresenta a tela resultante.

A JSTL foi discutida em detalhes na coluna "Pente Fino", nas Edições 7, 8 e 9. Veja também a coluna "Java Livre" nesta edição, que demonstra a uso da JSTL em uma aplicação web (mas sem uso do Struts).

Mensagens e internacionalização

Quantas vezes você precisou alterar dezenas de páginas porque uma mensagem ou um nome de botão comum foi modificado? Pois bem, com o Struts pode-se definir num único local (no arquivo ApplicationResources.properties) as mensagens de erros e os valores exibidos em botões, textos em HTML e outros componentes visuais. E não é necessária a recompilação para que as mudanças passem a valer.

O ApplicationResources.properties é usado também para internacionalização através das classes Locale e ResourceBundle (veja o quadro "i18n e Java"). Esse arquivo pode ter qualquer nome, mas a extensão .properties é obrigatória. Deve ser criada uma versão para cada idioma, além do default. Suponha que usemos o prefixo padrão "ApplicationResources", então o arquivo com as mensagens default deve chamar-se ApplicationResources.properties e conter as mensagens no idioma default do servidor. Para mensagens em outros idiomas o arquivo deve ter o nome ApplicationResources_xx.properties, onde xx é o código ISO para o idioma. Por exemplo podemos ter ApplicationResources.properties com mensagens em inglês e ApplicationResources_fr.properties com mensagens em francês.  É possível também especificar o país, tratando variantes de idiomas como pt_BR para o português do Brasil.

Dessa forma, poderíamos ter um arquivo ApplicationResources.properties com o seguinte conteúdo:

pagina.titulo=Welcome to SouJava!

label.user=User

label.password=Password

E um arquivo ApplicationResources_pt_BR.properties com as mensagens correspondentes para o Brasil:

pagina.titulo= Bem-vindo ao SouJava!

label.user=Usuário

label.password=Senha

Veja dois JSPs simples demonstrando a internacionalização na Listagem 4 e um exemplo de  " [...] continue lendo...