JSP Standard Tag Library (JSTL): Adicionando recursos na camada de visão

Veja nesse artigo como adicionar inteligência, elegância e recursos a uma camada de visão no JSP Standard Tag Library (JSTL).

Fique por dentro
O principal objetivo deste artigo é mostrar uma ferramenta que pode ser considerada um meio termo entre a utilização de robustos e badalados frameworks e o desenvolvimento espartano de JSPs fazendo uso apenas de scriptlets.

Agregando a elegância de frameworks como JSF, Spring e Struts, (utilizando apenas tags e expression language, sem as classes de suporte para a camada de visão) e a simplicidade de projetos web dinâmicos (compostos apenas por servlets e JSPs), JSTL tem mais algumas vantagens que veremos no decorrer deste artigo.

Desde o final dos anos 70, a separação de sistemas em camadas tornou-se uma espécie de mantra invocado por todos os desenvolvedores, em particular um modelo conhecido como MVC (Modelo, Visão e Controle), onde a ideia principal é ter camadas independentes e desacopladas, sendo o Modelo a representação do mundo real no sistema, a Visão é a interface com os usuários/sistemas e o Controle é a cola entre eles, que manipula os componentes de Modelo para serem exibidos na Visão e define o fluxo da aplicação.

Nos sistemas web, a camada de visão é representada por páginas HTML, estáticas ou providas pelos contêineres web. No caso do Java, temos os JSPs como os principais responsáveis pela geração da saída, que será enviada pelo contêiner web para o usuário.

O JSP, do ponto de vista de um desenvolvedor, nada mais é do que um HTML com tags especiais para podemos inserir código Java nele e isto permite que, em teoria, um sistema inteiro (acessando banco de dados, web services e sistemas de arquivos) seja construído em um arquivo deste tipo.

No entanto, o cenário de um sistema de uma página só é o pesadelo de arquitetos e responsáveis pela manutenção deste, por ter como resultado arquivos grandes, complexos e sem fazer uso de boas práticas de orientação a objetos, tais como encapsulamento, herança, etc.

O cenário ideal, do ponto de vista do MVC, é ter um ou mais servlets, acessando as classes de manipulação de dados, aplicando as regras de negócio e mandando as informações necessárias para exibição no JSP.

O JSP, por sua vez, recebe essas informações e seu único trabalho é definir onde, como e se as informações serão exibidas.

Usando apenas JSP, suas tags e expression language, é possível apresentar as informações fornecidas pelo servlet. Contudo, quando uma página requer um pouco de lógica (como percorrer uma lista para montar uma tabela, ou exibir um texto em preto ou azul, por exemplo), um scriptlet torna-se necessário.

E qual é o problema nisso? Para um desenvolvedor, nenhum, exceto pela legibilidade do código. Agora, e se, digamos, parte da equipe do projeto responsável pela interface com o usuário for composta por web designers, ou pessoas sem tanta familiaridade com Java?

Neste caso, é mais fácil ensinar para um web designer o funcionamento de algumas tags e seus atributos, pois este já deve ser familiarizado com tags HTML, a ensinar Java e seus conceitos (sintaxe da linguagem, orientação a objetos, etc.).

Uma ferramenta útil para fazer a interface entre o desenvolvedor e o web designer é o JSP Standard Tag Library, ou JSTL. O JSTL é um conjunto de classes e tags que levam à camada de visão, onde o web designer pode trabalhar as ferramentas utilizadas por desenvolvedores (estruturas de repetição, condicionais, etc.) sem que o web designer precise conhecer Java.

As classes que fazem parte do JSTL seguem uma especificação, a JSR-52, a qual pode ser implementada por qualquer pessoa ou empresa. Uma instituição que implementou e distribuiu a sua versão do JSTL foi a Apache Foundation.

Nesta distribuição são encontradas classes que são heranças ou implementações de interfaces suportadas por todos os servidores de aplicação compatíveis com Java EE 5. Por conta desta condição, para adicionar o suporte à JSTL em uma aplicação, não é necessária a adição de nenhuma biblioteca adicional (exceto, como veremos um pouco mais à frente, quando são utilizadas tags que processam XML, pois estas dependem de bibliotecas terceiras para fazer tal processamento) além da implementação de JSTL distribuída pelo fornecedor, não causando grande impacto no tamanho final de sua aplicação.

As classes definidas pela especificação compõem um conjunto de quatro grupos de tags, listados a seguir:

· Core: conjunto de tags que fornece as ferramentas mais comuns de linguagens de programação, tais como: estruturas condicionais, de repetição, definição de variáveis e impressão de conteúdo (neste caso para uma saída HTML);

· Internationalization: conjunto de tags que auxilia na disponibilização de conteúdo para outras línguas ou outros países. São úteis para formatação de datas, horários e números e para exibição de mensagens de acordo com o Locale/idioma do cliente.

Na disponibilização de conteúdos em diferentes idiomas, mesmo que um sistema seja concebido inicialmente apenas em um idioma, vale a pena utilizar as tags de mensagens, pois elas substituem textos por chaves que são definidas, assim como seus valores, em um arquivo texto, de maneira centralizada e de fácil manutenção. Também é conhecida por i18n, ou seja, i + 18, das letras que compõem o meio da palavra internationalization, + n;

· SQL: é um conjunto de tags que possibilita a criação de conexões com bancos de dados, bem como a posterior manipulação dos destes (instruções de inserção, exclusão, atualização e consulta dos dados).

No entanto, a utilidade deste conjunto é questionável, pois a manipulação de dados é algo que definitivamente não é aconselhável que seja feita na camada de visão. Lembrando que uma das ideias do uso de JSTL é que um web designer não precise conhecer Java, no entanto com as tags de SQL, pressupõe-se que ele conheça SQL;

· XML: semelhante ao conjunto de tags Core, contudo destinado à manipulação de arquivos XML. Embora útil para manipulação de algum conteúdo remoto (RSS, por exemplo), cai na mesma questão levantada para as tags SQL, a manipulação de dados na camada de visão." [...] continue lendo...

Artigos relacionados