Rafael Ponte

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.

Todo desenvolvedor que se utiliza de JavaServer Faces deveria saber como funciona o mecanismo de geração de identificação (ID) dos componentes, pois uma hora querendo ou não ele precisará deste conhecimento, principalmente se houver a necessidade de se escrever algum código JavaScript.

Enfim, vamos ao que interessa..

Entendendo o mecanismo

Uma das caracteristicas do JSF é que todos os seus componentes possuem um atribudo “id” e este atributo deve conter um valor único, caso não seja definido um ID pelo desenvolvedor então será gerado automaticamente um ID único para cada componente durante a construção da árvore de componentes.

Sendo, observem o seguinte trecho de código JSF:

<h:form>
	<h:inputText id="nome"/>
</h:form>

No final será gerado para o cliente (browser) o seguinte código -ou algo parecido- (X)HTML:

<form id="j_id_jsp_1761815803_1" name="j_id_jsp_1761815803_1" method="post">
	<input id="j_id_jsp_1761815803_1:nome" type="text" name="j_id_jsp_1761815803_1:nome" />
</form>

Reparem que o atributo “id” do componente h:form não foi definido, porém o framework gerou um ID único para o componente, no caso o ID foi “j_id_jsp_1761815803_1“, que foi renderizado juntamente com a tag <form/> do (X)HTML.

Atentem também que o ID (gerado) do componente h:form foi concatenado ao ID (que nós definimos) do componente h:inputText separados por ‘:’ (dois pontos) na tag <input/>, logo o ID da nossa tag <input/> é “j_id_jsp_1761815803_1:nome“.

Infelizmente os IDs gerados pelo framework não são nada legíveis para nós desenvolvedores -e provavelmente não deveriam-, então para consertar isso basta definirmos o ID de cada componente na nossa página, logo nosso código JSF ficará assim:

<h:form id="form">
    <h:inputText id="nome"/>
</h:form>

E consequentemente o código (X)HTML gerado será algo semelhante a isto:

<form id="form" name="form" method="post">
	<input id="form:nome" type="text" name="form:nome" />
</form>

Como podem ver, os IDs na página gerada ficam bem mais legíveis, facilitando assim o trabalho com JavaScript no lado cliente.

Naming container

E onde afinal de contas entra essa história de Naming Container?

Se vocês observaram o componente h:inputText teve seu ID concatenado ao ID do formulário no cliente, ou seja, na tag <input/> (X)HTML, e isso aconteceria com todos os componentes dentro do componente h:form. Logo, o componente h:form é um componente e ao mesmo tempo um naming container.

Basicamente, Naming Container é uma caracteristica que alguns componentes possuem, caracteristica essa que o framework utiliza para garantir que dentro de um naming container (componente) seus componentes filhos possuam IDs  únicos, evitando assim a duplicidade de componentes com o mesmo ID na página (viewroot).

Outra caracteristica importante que você deve saber sobre naming containers é que eles podem ser aninhados, logo os componentes mais internos terão seus IDs no cliente concatenados com os IDs dos naming containers mais externos também.

Logo em um caso como:

<h:form id="form">
    <f:subview id="subview">
        <h:inputText id="nome"/>
    </f:subview>
</h:form>

Teríamos o código (X)HTML abaixo gerado:

<form id="form" name="form" method="post">
	<input id="form:subview:nome" type="text" name="form:subview:nome" />
</form>

O componente f:subview também é um naming container, porém ele não gera qualquer output no cliente, ele é utilizado basicamente para servir como naming container, principalmente quando se faz includes de páginas dinâmicas.

Simples até demais, não?

Componentes padrões como h:form, f:subview e h:dataTable são naming containers. A maioria dos conjuntos de componentes possuem alguns naming containers, logo isso depende do conjunto de componentes.

Evitando naming container no formulário

As vezes temos páginas simples em que o único naming container é o próprio componente h:form, e nestas páginas precisamos manipular alguns dados no formulário através de JavaScript, porém é algo realmente chato ficar concatenando IDs para obter o ID de um input do formulário.

Para resolver isso o componente h:form (no JSF1.2) possui o atributo “prependId” que define se o componente se comportará no cliente como naming container ou não. Para evitar que o h:form se comporte como naming container basta setarmos o atributo “prependId” para false. Assim quando o código (X)HTML for gerado para o cliente as tags internas não terão seus IDs modificados.

<h:form id="form" prependId="false">
    <h:inputText id="nome"/>
</h:form>

Sem complicações, certo?

Essa caracteristica funciona somente para os componentes filhos do h:form, caso haja um naming container dentro do h:form então os filhos deste name container terão seus IDs alterados normalmente no cliente.

Concluindo

O post ficou até longo para um assunto básico, mas acredito que consegui abordar os fundamentos sobre naming container para quem pretende apenas utilizar os componentes na construção de páginas. Para quem realmente pretende criar (ou estender) seus próprios componentes seria interessante conhecer o conceito mais a fundo.

Enfim, o conceito é básico, porém fundamental para desenvolvedores que usam JavaServer Faces. Contudo é incrível como a maioria dos desenvolvedores não se interessam pelos fundamentos do framework, fundamentos estes que evitariam diversas dúvidas e problemas durante o desenvolvimento.