JSF: Stateful

O protocolo HTTP de certa forma é limitado, e uma dessas limitações é justamente ser stateless não mantém o estado com o cliente, ou seja, não possível somente com o protocolo reconhecer um determinado cliente além de um processo de requisição (request).

Em muitos sistemas web devemos driblar esta limitação, e usar alternativas do ambiente. Bom mas o que importa para este post, é que o faces trabalha mantendo o estado da view de um cliente, ou seja, é stateful. Justamente para efetuar todo o trabalho com Conversores + Validadores + Event / Action Listener. O faces tem 2 abordagens para stateful:

1. server-side: usando o HttpSession para manter os dados.
2. client-side: campos hidden para guardar as informações. Esta abordagem é menos segura que a outra.

Por default o my-faces usa a primeira opção, mas é permitido trocar a abordagem informando um parametro ao Faces Servlet, no web.xml.

JSF - Request Lifecycle

Continuando na "brincadeira" com faces, resolvi postar algo interessante do frame, o ciclo de vida da request, que é quem permite que várias features do frame tenham funcionalidade. Um detalhe importante, é que todo o esquema descrito abaixo, é possível pq o faces é stateful com seus componetes.

No geral, o ciclo de vida é executado de 2 formas:
a) Primeira requisição da página (View), o faces executa 2 fases:

• Restore View: verifica que ainda não existe árvore de componentes UI para a View, portanto cria todos os componentes UI (javabean) e passa para a fase de renderização.
• Render Response: baseado na estado (dados) dos componentes na tree monta a renderização no formato esperado pelo cliente.
  

b) Segunda requisição da mesma página, aonde a árvore existe e o fluxo de execução muda, é executado em 6 fases:

• Restore View: retorna a árvore vinculada a View, passa para próxima fase.
  
• Apply Request Values: captura os dados de input do cliente (param na request) e seta nas devidas properties dos componentes UI. Passa para a próxima fase.
  
• Process Validations: cada componente UI poderá ser validado, portanto nessa fase a árvore de componentes da view e percorrida, componente a componente, verificando se o componente UI tem validador, caso tenha o mesmo é executado. Se algo estiver errado pula para a fase de renderização, senão para a próxima.
• Update Model Values: os componentes UI já possuem as properties atualizadas, mas os "dados de modelo", ou seja, atributos dos managed bean ainda não! É importante relembrar que todos os param da request são String, e as properties dos compoentes UI tbém. Nessa fase serão aplicados os conversores, qdo existirem, na mesma forma que os validadores. Se algo estiver errado pula para a fase de renderização, senão para a próxima.
• Invoke Application: nesta fase são executados os actions listener registrados para os componentes Command (botões, links, ...) , e depois as actions normais (managed bean). Executada a fase de renderização.
• Render Response: a mesma política, renderiza o conteúdo para o cliente.