Um das decisões mais debatidas em JSF ou Seam e que os desenvolvedores dão pouca importância é onde salvar a árvore de componentes da view. Há duas opções disponíveis: do lado do cliente (client-side) e do lado do servidor (server-side), cada uma com suas vantagens e desvantagens.

Para entender melhor, vamos ver o ciclo de vida do JSF, entender em que contexto se encontra a criação da árvore de componentes, e porque ela existe:

Ciclo do JSF

A árvode de componentes do JSF é uma estrutura baseada em XML que identifica os componentes que estão na view. Quando se usa o JSF cada elemento da tela será associado a um espaço na árvore. O estado da árvore é armazenado para quando houver uma requisição do tipo postback*, alterações nos campos do formulário sejam aplicados às propriedades associados a esses campos e quaisquer eventos sejam enfileirados e invocados na sequência.

Na figura acima, observamos que da fase Restore View sai uma seta direto para a fase Render Response, ilustrada pela expressão “No Query Data”. Essa situação acontece quando temos uma requisição inicial em JSF (initial request), ou em uma forma mais simples de entender, quando chamamos uma tela pela primeira vez. É nesse ciclo de  apenas 2 fases que a árvore de componentes da view é criada. Uma vez que o response é processado, a árvore é serializada e enviada junto com o response para o cliente ou armazenada na sessão HTTP do usuário sob uma chave única.

A configuração

Para configurarmos o local onde salvamos a árvore de componentes, utilizamos um contexto de parâmetro chamado javax.faces.STATE_SAVING_METHOD no web.xml, conforme o código abaixo mostra:

<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>

Caso não se especifique nada, o local padrão será no servidor.

As abordagens

Server-side

Salvando o estado no servidor, a árvore de componentes é armazenada na sessão HTTP do usuário. Um token é enviado junto com o response e armazenado em um campo hidden. Posteriormente esse token é usado para recuperar a árvore da sessão em um postback*.

Client-side

A árvore é serializa, compactada, codificada e enviada junto com o response para o browser do cliente. O processo é invertido no postback* para que a árvore possa ser recuperada.

Vantagens X Desvantagens

E então, qual opção utilizar?

No livro Seam in Action, o autor Dan Allen sugere que se utilize a abordagem salvando no servidor. Ele alega que é muito ruim deixar o usuário esperando alguma resposta do sistema, pois, assim como temos pessoas com boa conexão ligadas à rede, existem aquelas que não possuem uma boa banda. Na minha opinião, faltou ele ressaltar que outros fatores devem ser pesados, como:

1. O sistema é interno e a qualidade da rede é satisfatória?
2. Quantas usuários simultâneos meu sistema terá?
3. O servidor tem uma boa configuração?
4. O sistema possui telas muito complexas, com formulários muito complexos?

Isso posto, acredito que algumas situações podem também favorecer a abordagem client-side. Para você que está começando, os itens acima podem lhe dar um bom “norte”.

Referências

• ALLEN, Dan; Seam in Action: Manning, 2009. 590 p.
• PONTE, Rafael.STATE_SAVING_METHOD – server ou client ?. Disponível em: <http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/> Acesso em: 29 de agosto de 2009.

Kyle Gallant(http://www.kylegallant.com/) finished the banner for me. We are fussing around a bit to recenter it and stuff, but it looks fantastic. Thanks alot kyle.