CDI: Não use @Inject e @ManagedBean nas suas classes

Algumas semanas atrás tive uma experiência bem estressante e chata ao misturar as anotações do JSF com as anotações do CDI. Apesar de saber que EM TEORIA eu não deveria fazer isso eu acabei fazendo e percebendo o problema NA PRÁTICA.

O problema ocorria quando minha página processava uma EL (Expression Language) que apontava para um managed bean anotado com @ManagedBean e tinha suas dependências injetadas pelo CDI através da anotação @Inject… nesse momento a injeção não ocorria. Sendo mais específico, simplesmente o container (qual deles? JSF ou CDI?) injetava null no atributo da classe. O código era semelhante a este:

@ManagedBean
public class AlunosBean {

    @Inject
    private AlunosDao dao;

}

A coisa fica ainda mais feia quando misturava os escopos do CDI com o escopos do JSF. Imagina um managed bean sendo instanciado trocentas vezes? Pois é…

Depois de muito ler e discutir com amigos que sacam mais de CDI do que eu, como o Raphael Lacerda e Daniel Cunha, eu percebi que NÃO era uma boa prática misturar as anotações. Para você entender mais a fundo do que estou falando eu bloguei no blog da TriadWorks sobre isso. Você pode ler o post completo no link abaixo:

>>> NÃO misture anotações do JSF com as anotações do CDI

O post fala um pouco sobre meu problema e de quebra ensina como você pode migrar seus managed beans do JSF para beans do CDI. Onde com certeza essa é a melhor escolha que você poderia tomar.

Enfim, uma experiência interessante que quis compartilhar.

Performance: Habilite o cache de páginas do Facelets

Na primeira requisição a uma página JSF o Facelets se encarrega de carregar a página do disco, processar tag a tag e construir uma estrutura em memória. Essa estrutura é cacheada para que nas requisições seguintes à mesma página o Facelets não precise recarregar o XHTML do disco. Você já consegue imaginar a vantagem disso?

Esse cache de páginas pode diminuir significativamente o tempo de resposta a uma página JSF. Mas tem um porém que você precisa ficar ligado…

Esse cache dura somente 2 segundos por padrão. Após esse período ele é invalidado e o Facelets é obrigado a recarregar e processar a página do disco novamente. O Facelets terá que recompilar a página novamente! Mas podemos configurar esse intervalo indefinidamente, dessa forma o cache nunca será invalidado.

Para isso, você pode ler nosso post no blog dos desenvolvedores da TriadWorks: Facelets: desligue o cache de páginas em desenvolvimento

Se você configurar o cache adequadamente para o ambiente de desenvolvimento você consegue melhorar sua produtividade pois não precisará esperar aqueles segundinhos antes de teclar F5 (refresh) para ver sua modificação no browser.

Cuidado com o timezone ao trabalhar com JSF 2

Se você, assim com eu, é um desenvolvedor Web então há grandes chances de você já ter gravado data e hora errada no banco de dados por causa do fuso horário (timezone), certo? Esse problema é muito comum quando desenvolvemos sistemas para Web, mas ele parece ser um pouco mais rotineiro ao trabalhar com JSF pois ele define um fuso horário padrão para seus conversores de data: UTC.

Apesar da boa intenção do JSF, essa definição padrão acaba complicando nossa vida e pior, só percebemos esse problema em produção, quando os dados já foram corrompidos – aí já era, né!. Mas não se preocupe, existem algumas práticas com JSF que podem te ajudar a contornar de forma simples e prática:

http://blog.triadworks.com.br/jsf-conversao-de-datas-e-problemas-com-fuso-horario

Além de entender o problema e aprender a resolvê-lo você também aprende algumas boas práticas sobre como trabalhar com fuso horário na sua aplicação Web, pois gerenciar múltiplos fusos horários não é tarefa trivial.