Problema do rendered dinâmico com JSF

Desde o surgimento dos conjuntos de componentes Ajax passou-se a aproveitar melhor as features do JSF e destes componentes para trazer ao usuário uma UI mais rica e na medida do possível mais leve. Graças a estes componentes ficou mais fácil desenvolver estes tipos de UI quase que transparentemente da mesma forma convencional (sem Ajax) que estávamos acostumados a escrever nossas páginas.

Entre tantos benefícios dessa abordagem apareceram alguns problemas que também não estávamos acostumados a lidar, como saber o que enviar e repintar antes de uma requisição Ajax, ou saber limpar um formulário adequadamente quando necessário ou mesmo repintar determinados componentes de exibição dinâmica.

Pegando este último problema como tema deste post, o que eu tenho notado é que ainda hoje em dia ele é um dos problemas mais comuns de acontecer e ao mesmo tempo um dos mais discutidos em fóruns e listas de discussão. Sendo, nada mais justo do que explana-lo aqui no blog e facilitar a vida de muitos, assim como a minha.

Problema

Este problema, que muitos ainda desconhecem, é comumente conhecido como “problema do rendered dinâmico” (bem, ao menos é como eu o chamo!) e só acontece quando trabalhamos com JSF e Ajax – independente do conjunto de componentes – mais especificamente após tentarmos repintar (ou rerenderizar, como você queira chamar) um componente com o atributo rendered dinâmico, como este:


    

Este componente poderia ser repintado após algum evento Ajax disparado pelo usuário na tela, como por exemplo ao selecionar o tipo de cadastro entre pessoa física ou jurídica, algo similar a isto:


    
    
    

Aparentemente não há qualquer problema com os trechos de código acima, principalmente se o componente iniciar visível para o usuário (ou seja, a EL ${myBean.pessoaFisica} do rendered estiver sendo avaliada para true).

Após mudar para o tipo pessoa jurídica é disparado um evento Ajax, o componente é repintado e desaparece da tela, como era de se esperar, claro. Contudo se você alterar a opção para o tipo pessoa física o componente não reaparecerá para o usuário. E é aí onde está o problema!

Se você for esperto, após alguns minutos analisando o problema, notará que a requisição Ajax foi disparada pelo componente tipoDePessoa (Firebug, plugin para Firefox, pode te ajudar aqui), o estado do managed bean foi alterado e o ciclo de vida do Faces foi processado sem qualquer erro.

E a partir daí, depois de refazer e analisar todos os passos básicos e sensatos, perde-se inúmeras horas tentando descobrir onde está de fato o problema neste simples cenário. A primeira vista parece ser um bug do JSF ou do conjunto de componentes, mas na verdade não é.

Solução

Sendo direto e sem rodeios: você não pode rerenderizar um componente na qual possua o atributo rendered dinâmico, ou seja, o componente não pode possuir EL para definir seu estado de visibilidade para o usuário.

Para resolver isso, repinte o componente parent do componente que possui o rendered dinâmico. Lembrando que este componente parent não pode ter o atributo rendered dinâmico, ou seja, ele sempre precisa ser renderizado.

Componentes como a4j:outputPanel ou mesmo h:panelGroup são excelentes componentes para servirem como componente parent. Sabendo disto, o código apropriado seria algo como:


    
        
    

E o componente responsável pelo evento Ajax deve repintar, no caso acima, o a4j:outputPanel (componente parent sem rendered dinâmico) e não mais o h:panelGroup.

Entendendo o problema

Para quem ainda não sabe, o atributo rendered (que por padrão é true) dos componentes é responsável por tornar o componente visível ou não para o usuário, ou seja, sempre que este atributo for true o componente poderá gerar código XHTML para ser exibido na página. Caso ele seja false, normalmente, nenhum código XHTML é gerado. Vale lembrar que mesmo o rendered sendo false o componente ainda existe na árvore de componentes no lado servidor.

Não é interessante tentar rerenderizar um componente com rendered dinâmico pois quando o atributo rendered é avaliado para false o componente (código XHTML na verdade) não aparece na árvore DOM da página. Sendo, após repintar este mesmo componente (agora com rendered avaliado para true) o código JavaScript do Richfaces responsável por atualizar o bloco de código onde se encontraria o componente na árvore DOM não consegue achar a posição exata para repintar na página (para injetar o novo código XHTML), já que o código XHTML do componente não existe mais. Então, no final, o Javascript do Richfaces acaba simplesmente não fazendo nada.

Por isso, quando você repinta um componente parent qualquer (que sempre tem o atributo rendered avaliado para true) o Richfaces consegue encontrar a posição exata deste componente na página e injetar o novo código XHTML, e como o componente com rendered dinâmico é um nó (filho) do componente parent ele também é repintado.

Concluindo

O problema é simples e a solução mais simples ainda! Nada como ler a documentação do seu conjunto de componentes favorito para entender e evitar este problema. Vale salientar que este problema ocorre com praticamente todos os conjuntos de componentes Ajax.

Acho que para um assunto simples como este eu falei mais do que devia. Espero que tenha ficado claro ou ao menos tenha dado uma luz para quem está enfrentando essa dor de cabeça. Caso queria saber mais sobre o assunto você poderá consultar a documentação do Richfaces, mais especificamente os tópicos 5.5 e 5.6.1.

Enfim, estou feliz por ter tirado mais um post antigo da minha lista de drafts! Atualmente minha rotina diária não tem me permitido investir o tempo que eu gostaria para blogar, mas cá estamos nós novamente, certo? :-)

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.