Aplicações sérias em JSF usam Facelets

Não há exagero no título do post, de fato, aplicações sérias desenvolvidas em JSF deveriam utilizar Facelets. Desenvolvedores que abrem mão de todas as vantagens oferecidas por este framework estão “pisando na bola”.

Já é de conhecimento da maioria que JSF sozinho [apenas a implementação] não nos fornece os recursos necessários para desenvolver médias ou grandes aplicações webs de maneira produtiva, o framework possui vários problemas (mas qual não possui?), muitos deles são facilmente resolvidos com a adoção de algum framework ou conjunto de componentes, outros podemos resolver apenas com algum conhecimento/conceito base sobre o framework ou seguindo algumas boas práticas.

E por falar em boas práticas, certamente uma das melhores práticas -e praticamente obrigatória- é a utilização de algum framework de templating para construção das páginas, não somente em JSF, claro.

Pois se estamos trabalhando com páginas, por que então não utilizarmos algum framework para definição de templates?

Templating frameworks

Hoje existem várias opções de frameworks com essa finalidade, porém a grande maioria deles não foi desenvolvido para trabalhar com JSF, a maioria deles não foi desenvolvido para trabalhar de acordo com o ciclo de vida das requisições processadas pelo JSF. Alguns deles funcionam até bem, porém com toda certeza em determinados momentos eles te deixarão na mão.

Acredito que hoje os frameworks para definição de templates mais comuns são o Struts Tiles e o Sitemesh, ambos funcionam bem com JSF até que em algumas situações os problemas começam a surgir, problemas como perda do FacesContext, código duplicado, conflito de componentes, funcionalidades AJAX param de funcionar etc. Sendo, com certeza nem Struts Tiles nem Sitemesh são boas opções de frameworks para se trabalhar com JSF.

Pior do que usar um dos dois frameworks citados acima é criar seu próprio mini-fashion-templating-framework, seja utilizando-se de JSP taglibs ou mesmo de um Servlet Filter, não importa, fuja disso, evite reinventar a roda, aliás, evite reinventar uma roda ainda pior do que as já existentes [não quero entrar na discussão dos malefícios de criar seu framework caseiro].

A melhor opção

Já faz um bom tempo que temos excelentes opções de templating frameworks desenvolvidos especialmente para JavaServer Faces como o Facelets ou JSFTemplating. Ambos trabalham perfeitamente bem com JSF e trazem diversos benefícios tanto em termos de perfomance como em produtividade.

Mas com toda certeza o mais utilizado, mais popular, com maior suporte da comunidade, maior documentação e provavelmente mais estável entre eles é o Facelets.

Iniciar um projeto web com JSF e não adotar Facelets é começar um projeto “pisando na bola”, é abrir mão de diversos benefícios para a equipe de desenvolvedores e para a aplicação em si.

Facelets possui várias vantagens que vão desde a facilidade na criação e reutilização de páginas e componentes, melhor depuração de erros, AJAX nativo, uma melhor compatibilidade entre XHTML, JSTL e os componentes, ele é independente de web container, e claro, Facelets é de 30% a 50% mais rápido que JSP.

Ah, claro, como poderia esquecer, JSF2.0 adotou Facelets como view handler padrão, então, provavelmente migrar uma aplicação de JSF1.2 (ou mesmo JSF1.1) para JSF2.0 será menos trabalhoso ainda caso você não o estive usando.

Estas são somente algumas vantagens ao se adotar Facelets em um projeto, existem várias outras, mas eu considero estas como as principais.

Concluindo

Infelizmente JSF1.2 utiliza-se de JSP como view handler padrão por questões políticas e principalmente comercias, mas acreditem em mim, eles são como água e óleo, não combinam juntos. Para falar a verdade, por que você acha que todos os exemplos dos produtos da JBoss (Richfaces, Seam etc) estão utilizando-se massivamente de Facelets e não de JSP?

Enfim, não há motivos para não adotar Facelets em um novo projeto ou mesmo em um projeto já em andamento [é possível ir migrando de JSP para Facelets aos poucos], todos os conjuntos de componentes que conheço funcionam perfeitamente bem com ele e algumas vezes até melhor, o que não falta são artigos, blogs, tutoriais, fóruns, revistas e listas de discussão com informações suficientes para configurar e tirar melhor proveito do Facelets na sua aplicação.

Volto a dizer, iniciar um projeto sério em JSF sem adotar Facelets como framework para templating é começar errado. Eu falo sério.

Algumas boas práticas com JSF e Richfaces

Esses dias eu estava fuçando meus arquivos e encontrei uma apresentação que eu havia utilizado para uma consultoria numa empresa muito conhecida no mercado local. A empresa estava adotando Jsf, mais especificamente Jboss Richfaces, como solução para a camada de visão de uma nova aplicação web que eles pretendiam desenvolver.

Na época, por volta de um ano atrás, fui contratado para ministrar um treinamento sobre como aplicar boas práticas no desenvolvimento com a tecnologia Jsf, pois a equipe de desenvolvedores desta empresa tinha o receio de não conseguir obter proveito dos recursos dos frameworks adotados, como também era de interesses deles “tunar” a utilização de AJAX na aplicação e por fim, como integrar Jsf com o framework javascript ExtJs.

A apresentação está bem simples, serve somente como resumo sobre o que foi passado à eles, porém apenas observando-a é possível saber como conseguir um melhor proveito dos frameworks e conjuntos de componentes ao redor de Jsf, principalmente no aspecto da utilização dos recursos AJAX oferecidos por vários dos componentes do Richfaces.

Algumas das práticas contidas nos slides já foram muito discutidas por aqui, outras eu sempre comento um pouco em alguns posts e na maioria das vezes elas foram muito discutidas na lista do JavaServer Faces International Group.

Algumas das dicas sobre a utilização do Richfaces/Ajax4jsf podem ter mudado de alguma forma no decorrer das versões do framework, outras features certamente surgiram para ajudar na melhor utilização dos componentes e recursos AJAX, contudo, a chave para “tunar” o Richfaces ou qualquer conjunto de componentes AJAX basicamente é:

  • Antes de enviar uma requisição AJAX decida o que enviar;
  • Antes de enviar uma requisição AJAX também decida o que atualizar;

Enfim, muito do que se foi discutido na apresentação está bem mais clara e fácil de encontrar hoje na documentação dos frameworks e conjunto de componentes, blogs, listas de dicussão, fóruns e artigos em revistas especializadas.

Estendendo JSF EL com JBoss EL

Uma das features que faz falta na JSF EL (Unified EL) é a não possibilidade de executar métodos sobre um objeto qualquer ou mesmo passar parâmetros para um método, isto é, não é possível por exemplo se utilizar de uma EL como #{managedBean.list.size()} ou #{managedBean.addSomeThing(row)}.

Enfim, atualmente a especificação nos limita apenas a obter propriedades de um objeto através de getters e setters ou obter os elementos de um map pelo nome. Contudo o pessoal da JBoss estendeu a JSF EL criando a JBoss EL -que hoje é utilizada no JBoss Seam– que traz diversas melhorias na expressividade e poder da expression language, entre elas a comentada um pouco acima.

Instalando

A instalação e configuração da JBoss EL no seu projeto é muito simples, e o melhor, não se faz necessário a instalação do JBoss Seam.

O primeiro passo é baixar a implementação da JBoss EL e então adicioná-la ao classpath (/WEB-INF/lib/) da sua aplicação, depois disso basta apenas adicionar um parâmetro de contexto no web.xml da aplicação para usar a lib:


	com.sun.faces.expressionFactory
	org.jboss.el.ExpressionFactoryImpl

Pronto! Você já pode se utilizar da JBoss EL para executar métodos e passar parâmetros para estes métodos quando necessário.

Features

O extensão traz diversas features interessantes e bastante utéis no nosso dia a dia, entre elas a já comentada passagem de parâmetros:


Podemos também escrever expressões como abaixo:


Bacana, não? Então o que vocês acham da feature a seguir?

Uma das features mais interessantes é a projection. Com ela é possível iterar coleções (list, set etc) de objetos de maneira simples através de sub-expressões, e o melhor, é possível iterar coleções aninhadas, algo realmente prático quando não se deseja escrever muito código nos managed beans.

Com a sintaxe de projections podemos fazer algo tão simples quanto:

#{company.departments.{d|d.name}}

Ou podemos ir mais longe com:

#{company.departments.{d|d.employees.{emp|emp.lastName}}}

É importante ressaltar que esta sintaxe não pode ser utilizada diretamente nas páginas (xhtml ou jsp) pois tanto Facelets quanto JSP não conseguem interpretá-la.

Limitações

Existem algumas limitações que se deve ficar atento, porém não é nada de outro mundo.

Eu particularmente considero a não compatibilidade com JSP 2.1 (isso mesmo, ela é compatível apenas com JSP 2.0) como a principal e a mais crítica da extensão, pois nem todas as aplicações com JSF 1.2 se utilizam de Facelets, mas deveriam, pois já é sabido de todos que qualquer aplicação séria desenvolvida em Jsf deveria utilizar-se de Facelets.

Então se você quer utilizar essa extensão com JSF 1.2 você deverá utilizar Facelets querendo ou não.

Concluindo

Aproveitem a extensão, evitem as gambiarras e as tentativas deploráveis de passagens de parâmetros utilizadas hoje em dia. A instalação da extensão é simples, a utilização é mais simples ainda, e o melhor de tudo é que há grandes possibilidade de fazer parte da JSR 314.

A extensão só tem a melhorar (versões futuras já estão sendo implementadas), principalmente em relação a sintaxe de projections (que poderá mudar em breve), possibilitando assim uma maior manipulação de coleções nas páginas.

Enfim, se seu projeto se utiliza de JSF 1.2 e você pretende utilizar a JBoss EL você já pode aproveitar e migrar suas páginas para Facelets, no final você e sua aplicação só tem a ganhar.