Cristiano Sanchez

Mês passado iniciei um projeto usando JSF, com a implementação ICEFaces. Após 1 ano sem mexer com JSF resolvi apostar no framework, não por capricho, como nenhuma escolha deve ser, mas pelas seguintes razões:

• O projeto é composto por 80% de operações CRUD (create, read, update e delete). Já temos o modelo de domínio pronto e alguns testes via IDE (netbeans e eclipse) mostraram que a criação de telas e operações seriam automatizadas;
• Outro ponto chave do projeto é a criação de um painel com a responsabilidade de apresentar de forma gráfica (estrutura de organograma) os dados cadastrados. Aparentemente a criação de um componente JSF é bastante atraente;
• A equipe é pequena, composta de 3 pessoas, e com níveis diferentes de conhecimento. Mas o fato de estarem juntas no mesmo projeto e ambiente facilitará a comunicação e transferência de conhecimento. A aposta deveria ser em um framework produtivo e de fácil absorção. Minha impressão sobre Struts2 e SpringMVC, apesar do modelo Action/Command já bastante difundido, é de que trazem uma curva de aprendizado maior que JSF;
• Existe muito material sobre JSF disponível em português, inglês; livros, blogs, apresentações e exemplos não seriam um problema;
• Alguns projetos em que a equipe é responsável por suporte e manutenção utilizam JSF;
• Escalabilidade não será um problema já que o projeto será utilizado por pouco mais de uma centena de usuários.

Resolvemos utilizar o Netbeans, apesar deste ainda utilizar a implementação Woodstock de JSF, a qual aparentemente será descontinuada dando lugar ao ICEFaces. Desta forma, os CRUDs gerados necessitaram de migração de Woodstock para ICEFaces, nada muito complicado, mas trabalhoso. Este não foi o único problema. Vários CRUDs mais complexos, onde existiam relacionamentos entre domínios, foram gerados com erro. Muita correção manual foi necessária e a tão desejada, tranquila e rápida geração de CRUDs baseada em domínio não aconteceu. Sem o auxílio de um IDE para auxiliar a programação JSF o framework perde muito de sua magia. As criação de views, managed beans, xml, etc traz lentidão ao trabalho.

Mesmo com problemas de produtividade o aprendizado do JSF se mostrou rápido entre a equipe mesmo entre os que não tem conhecimento avançado de JavaEE, especificamente, componentes web. O JSF abstrai bastante toda a iteração entre cliente, container e código. A criação de métodos-evento, o mapeamento das views, a criação de conversores e validadores, tudo é realmente fácil.

Configuramos o SiteMesh para gerenciar e compor as views, mesmo com todos avisos sobre a integração problemática entre JSF e SiteMesh. Está funcionando e não tivemos problemas.

Alguns acoplamentos do bean com o framework tornam testes unitários mais difíceis de realizar do que no SpringMVC, por exemplo. Contudo, pasmem os que acharem isto uma heresia, não teremos testes unitários na camada de apresentação por vários, vários motivos, que darão outro post sobre o assunto. De qualquer forma, a deficiência do JSF quanto a isto não será um problema.

Ainda é cedo para dizer como ficará o resultado final. O prazo é apertado e pode-se dizer que mesmo com todos as dificuldades de usar o JSF, estamos caminhando para uma entrega dentro do esperado, com uma boa curva de aprendizado pela equipe e com a promessa de que o IDE, Netbeans, melhore cada vez mais a integração com JSF.