Este blog trata de problemas em desenvolvimento de software, vivenciados

por mim no dia-dia e que podem ser de grande ajuda a outros

desenvolvedores.
tera-feira, 18 de maro de 2014

O Ciclo de Vida de uma requisio JSF

J desenvolvo em JavaServer Faces (JSF) h alguns anos e decidi escrever este post
respeito do ciclo de
vida de uma requisio.
Aps participar de diversos projetos JSF, fica bem claro que o framework
subutilizado. Mas, de certa forma, acaba sendo algo normal diante de tantos
problemas que temos pra resolver, acabamos que dando um jeito de codificar a
primeira soluo que aparece.
Acredito que isso acaba saindo caro futuramente, quando as manutenes comeam
a aparecer e os testes comeam a ser realizados.
Nesse caso, o conhecimento do ciclo de vida far com que a gente busque a melhor
maneira de solucionar certos problemas e eu vou tentar citar alguns exemplos neste
post.
A especificao JSF define um ciclo de vida constitudo em 6 fases: Restore View,
Apply Request Values, Process Validations, Update Model Values, Invoke Application,
Render Response. Tentarei resumir cada uma das fases abaixo.

Restore View
Esta fase a primeira e onde a rvore de componentes do JSF montada em
memria. Caso ela j tenha sido montada anteriormente, ento ela recuperada.
nesta fase que a classe FacesContext instanciada. Caso seja o primeiro acesso do
usurio na tela, todos os componentes sero lidos e atribudos a vore e, ento, a
ltima fase (Render Response) retornada. Caso o usurio pressione o boto
"Salvar", ento a fase Apply Request Values chamada.

Apply Request Values

nesta fase que cada um dos valores submetidos no formulrio vo ser atribudo a
cada um dos componentes da rvore atravs de uma iterao. Esses valores so
chamados de "localValues" (Valores locais). Aps a atribuio dos valores locais, a
fase de Process Validation chamada.

Process Validation

Nesta fase, cada uma das validaes e converses implementadas pelos

desenvolvedores so realizadas. Caso haja qualquer problema, a fase de Render
Response chamada e a pgina reexibida com a mensagem de erro apresentada
ao usurio. Caso no ocorra nenhum problema, a fase de Update Model Values
chamada.

Update Model Values

Se estamos nesta fase, porque os valores foram validados normalmente sem
qualquer problema. Neste momento, os valores locais (localValues), j convertidos,
so atribudos a seus respectivos atributos do managedbean.

Invoke Application
A ao "Salvar" submetida pelo usurio executada neste momento.

Render Response
Se o mtodo "Salvar" definiu a navegao para uma outra pgina, neste momento a
pgina ser montada e exibida no navegador.

Required = True e Validaes no Controlador

Agora que vimos um pouco do ciclo de vida, irei comentar algumas situaes que so
comuns em projetos que utilizam JSF.
J passei por situaes em projetos que o required=true foi simplesmente "proibido"
de se usar. O que ocorria que as mensagens de validaes apresentadas por
componentes requireds estavam sempre sendo validadas e exibidas em tempos
diferentes das validaes realizadas pelo nosso Controlador. Ou seja, era necessrio
preencher os campos obrigatrios e mandar salvar para ver uma nova lista de
mensagem de validao. No caso desse sistema, as mensagens de validaes
independentes entre si, deveriam ser apresentadas na mesma lista de erros.
Na poca, para resolver essa situao, a soluo adotada era: Apaga tudo que tiver
required=true e faz todas as validaes de campo obrigatrio no controlador! Mas isso
um caso normal e ocorre por falta de conhecimento do ciclo de vida. O que ocorre
neste caso que todas as validaes de componentes marcados como requeridos,
so realizadas na fase de Process Validation (terceira fase) e caso haja algum defeito,
o ciclo de vida interrompido e a resposta renderizada. J as validaes dos
controladores so feitas na fase em que a ao do boto processada, ou seja, na
fase Invoke Application (quinta e penltima fase).

Existe uma forma de centralizar as chamadas das validaes de controlador, com as

validaes de Validators e Requireds na fase de validao do JSF (Process
Validation), que atravs da tag <f:event /> , do tipo PostValidate, declarada no seu
XHTML com um listener de validao. Aps declarar esta tag, o listener de validao
ser chamado ainda na terceira fase, logo aps todos os componentes serem
validados.

Immedidate = True
O immediate bastante utilizado, principalmente em botes, mas acredito que ainda
muito confundido. Em resumo, a finalidade de componentes marcados como
imediatos, nada mais do que realizar o processamento do respectivo componente na
fase de Apply Request Values (segunda fase). Em outras palavras, seria antecipar a
execuo do processamento que seria realizado posteriormente, para ser executado
na segunda fase.

Botes e Links marcados com Immediate = True

Como vimos no resumo do ciclo de vida acima, o processamento dos botes so
realizados na fase de Invoke Application (penltima fase). Caso o boto seja marcado
como imediato, o "action" do mesmo ser executado na fase Apply Request Values
(segunda fase) e, em seguida, a fase Render Response ser chamada, ou seja,
fazendo com que todos os componentes nem sejam validados e nem submetidos em
seus respectivos managed beans. Um exemplo muito comum da utilizao de botes
marcados como imediatos para botes de "Voltar". Faz todo sentido, j que,
normalmente, no precisamos processar os componentes em tela no momento de
voltar.

Componentes de entradas (Inputs) marcados como Immediate = True

Normalmente as pessoas no costumam utilizar componentes de entradas como
imediatos. Mas existem alguns casos que so bem teis. Quando um componente de
entrada imediato, as validaes que antes ocorreriam na fase de Process Validation
(terceira fase), agora ir ocorrer na fase de Apply Request Values (segunda fase).
Utilizamos esta forma em casos de, por exemplo, 2 componentes em tela e o segundo
componente depende que o primeiro componente seja validado, para ento ele ser
validado. Nesse caso, colocamos o immediate=true no primeiro componente.

Como depurar uma pgina JSF?

BalusC mostra a depurao bem detalhada. Mas voc tem como opes utilizar
o faces-trace ou implementar um listener do ciclo de vida, desta forma:
Criar a classe LifeCycleJsfListener:

1.

import javax.faces.event.PhaseEvent;

2.

import javax.faces.event.PhaseId;

3.

import javax.faces.event.PhaseListener;

4.
5.

/**

6.

* Esse listener ir logar o incio e fim de cada uma das fases do JSF.

7.

*/

8.

public class LifeCycleJsfListener implements PhaseListener {

9.
10.

@Override

11.

public void beforePhase(PhaseEvent event) {

12.
13.

System.out.println("BEGIN PHASE: "+event.getPhaseId());

}

14.
15.

@Override

16.

public void afterPhase(PhaseEvent event) {

17.
18.

System.out.println("END PHASE: "+event.getPhaseId());

}

19.
20.

@Override

21.

public PhaseId getPhaseId() {

22.

return PhaseId.ANY_PHASE;

23.
24.

}
}

E, no faces-config.xml, adicionar a chamada do listener:

1.

<lifecycle>

2.

<phase-listener>infraestrutura.listener.LifeCycleJsfListener</phaselistener>

3.

</lifecycle>

Este listener torna a depurao bem fcil e, com isso, cada uma das fases do seu
sistema ser logada antes e depois da execuo.