JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.

html

ASSINE 0800 703 3000 BATE-PAPO E-MAIL SAC BUSCAR VOIP E-MAIL GRÁTIS SHOPPING ÍNDICE PRINCIPAL

Login Registre-se

HOME NOTÍCIAS ARTIGOS FÓRUM WIKI BUSCA SOBRE ENVIAR NOTÍCIA CONTRIBUIR O QUE É JAVA?

Home > Artigos > Frameworks, APIs, Instalação e Configuração >

JSF ciclo de vida

Publicado por ebarros em 02/06/2010 - 26.990 visualizações

comentários: 0

INTRODUÇÃO
Uma das partes mais difíceis de chegar até a velocidade desejada com JavaServer Faces é a complexidade introduzida pelo ciclo de vida. Este artigo pretende
desmascarar as medidas tomadas pelo FacesServlet (o coração do JSF), uma vez que os processos de cada solicitação é recebida. Este ciclo de vida formaliza como
implementações JSF que irá processar um pedido, e opções para expor o que você pode anexar no seu próprio processamento de aplicações específicas.

JSF Lifecycle
O ciclo de vida do JSF não é trivial, mas é de extrema importância, pois através dele você começa a entender o porquê de ocorrer certos erros, como Value is not valid
e entre outros erros de validação nas fases do framework web.

Necessidade de ter frameworks WEB

Vamos imaginar o seguinte cenário, onde você está desenvolvendo um exemplo
"servlet plain vanilla"
. Onde seu método de serviço servlet é invocado pelo container com pedido de resposta e objetos. Então seu método de serviço, irá precisar no mínimo de:

1. Solicitar e interrogar para poder extrair os parâmetros de entrada (via consulta repetitivas e tediosas).

2. Converter estes parâmetros de seqüências de seus tipos de dados correspondentes (todos os valores de entrada aparecem como strings).

1 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

3. Validar a presença dos parâmetros exigidos, a veracidade dos valores inscritos, formatação, entre outras.

4. Usar a URL de entrada ou de parâmetros para determinar quem deve processar a solicitação.

5. Executar o processamento de aplicativos usando os parâmetros de entrada e de qualquer estado salvo como entradas. Obter informações de vários âmbitos,
conforme necessário.

Sua lógica terá de armazenar os produtos de trabalho (ou Transfer Objects para a View) no âmbito adequado.

6. Determinar o ponto de vista que irá mostrar a resposta para o usuário (por exemplo, uma página JSP).

7. Escrever diretamente no objeto de resposta, ou avançar para a View pretendida. E Obter informações de vários âmbitos, conforme necessário.
Além de toda a configuração que eu citei acima, do qual se não for bem planejada e documentada, você acaba se perdendo em algum processo, se contar que em
minha opinião e quase impossível estabelecer um padrão de codificação, além disso, você também precisa de mecanismos de utilidade conectado a cada um destes
passos para lidar com:

a) Conversão, validação, aplicação, ou erros de sistema que podem ser descobertos;

b) Internacionalização das seqüências de recursos quando necessário;

c) Compõem exibições fora de usos (depreciadas ou depracated) e testes de cada camada;

d) A capacidade de acessar as propriedades do bean de vários escopos (contexto, sessão e pedido);

e) Ter uma lógica de controle de aplicativos com os serviços, que através desses serviços de localização possa permitir a injeção de dependência.

E você tem que repetir o procedimento acima para cada URL única que seu aplicativo deve lidar. Agora você acrescenta isso às dificuldades em descobrir como
gerenciar o mapeamento entre URLs e manipuladores, e como gerenciar os destinos das views uma vez que é feito através do processamento. E, Deus me livre, ter
que suportar renderização em WML também. Como você pode imaginar rapidamente você irá acrescentar uma complexidade muito grande no seu projeto.

Agora imagine que alguém te ajude a abstrair as partes comuns das tarefas acima, e deixar a maioria das tarefas sendo controladas através de um fill-in-the-blanks
(modelo onde você pode inserir sua funcionalidade personalizada). Isso é exatamente o que é um framework web faz. Ou seja, ele esconde o tedioso, mundano e
mente numbingly das tarefas maçantes de view, e expõe muito bem os pontos definidos no qual você pode ligar em sua lógica de aplicativo personalizado.
Mas então, o que JSF pode trazer de vantagem para o ponto de partida? Ele simplesmente traz todas as opções acima e adiciona em um modelo de componente
bastante singular stateful que ainda automatiza muito o trabalho que acima foi descrito.

Mas então, como flui um típico ciclo de vida do JSF?

1. JSF interroga o pedido para extrair os parâmetros de entrada (OK).

2. JSF converte estes parâmetros de seqüências de seus tipos de dados correspondentes (OK).

2 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

3. JSF valida à presença dos parâmetros exigidos, exigindo veracidade dos valores inscritos, entre outros (OK).

4. JSF usa a URL de entrada para determinar quem deve processar o pedido (OK).

Isso geralmente é feito usando post-backs.

5. JSF irá executar qualquer lógica personalizada que você fornecer. (OK).

Sua lógica irá armazenar os produtos de trabalho (ou Transfer Objects para a view) no âmbito adequado.
JSF define interfaces para manipuladores de eventos e orientações claras a respeito de quando um manipulador particular será invocado.

6. JSF determina a visão de quem vai mostrar a resposta para o usuário (OK).

JSF usa o valor de retorno de seu manipulador de aplicativo para procurar o ponto de vista desejado em um arquivo de mapeamento que você fornecer.

7. JSF irá executar qualquer lógica personalizada que você fornecer para processar a sua resposta, ou vai para frente para a view pretendida. (OK).

Durante todo estes processos (1 a 7 acima), o JSF fornece utilitários para erros para ser exposto para o usuário, para a internacionalização com pacotes de recursos,
entre outros. Além disso, o JSF não fornece um mecanismo de composição original(somente na versão 2.0 que juntou com o Facelets), logo assim você vai precisar
incluir Facelets(templates).
O modelo padrão reconhecido para o desenvolvimento web hoje é o Model-View-Controller (MVC). O JSF incentiva essa divisão na lógica do seu aplicativo
dando-lhe orientação sobre a forma como você pôde fazer essa divisão do trabalho possível. Com JSF, seus pontos de vista são os seus arquivos de modelo, o modelo é
uma combinação do seu modelo de componente (que suporta uma determinada página) e seu domínio ou modelo de aplicação (que contém as entidades do seu
domínio e regras de negócio) e seu controlador é uma combinação de FacesServlet (fornecido pelo JSF) e os manipuladores que você exponha.
Como você pode ver, há muito que JSF oferece. (Para ser justo, todos os frameworks web fornecer esse nível de apoio de maneira mais complexa ou mais simples,
depende do ponto de vista e de gosto).
O que é único para JSF (e para a maioria dos componentes orientados a frameworks) é um modelo de componente JSF UI, que acrescenta algumas vantagens
verdadeiramente únicas. Ele permite que o Map (java.util.Map) conjunto de parâmetros JSF, seja entrada de Strings para as propriedades do bean (com a conversão
de dados adequados). Isto é, ele permite que o JSF se lembre do estado em todo o componente de invocações. Isso permite que o JSF consiga compartimentalizar os
bits pluggable de funcionalidade, tais como processadores, conversores e validadores, em uma base por componente. E também permite que você manipule os
componentes diretamente no código Java. E muito mais.
Como pode ser visto o JSF te deixa fazer “quase tudo”, ou seja, não te deixa preso ao framework web, mas sempre devemos tomar os devidos cuidados com os
processos de ciclo de vida, senão você pode ficar preso uma exceção por muito tempo, como é explicado com detalhes no quadro abaixo.
Provavelmente, esta sua combinação de ciclo de vida complexo e flexibilidade do modelo de componentes JSF que faz os desenvolvedores web se sentir inatingível e
torná-lo numa visão não muito boa para as engenharias dos experientes desenvolvedores web. Ai que entre este artigo, vou tentar fazer que o ciclo de vida seja mais
acessível aos desenvolvedores, deixando assim o modelo de componente para o outro artigo que escreverei em breve.

Breve explicação sobre o quadro do ciclo de vida em anexo.

1. Cada caixa amarela é uma etapa de processamento distintas dentro do ciclo de vida e do processamento da solicitação.

2. Cada caixa verde representa o processamento de eventos opcionais, e dá a sua aplicação a oportunidade de inserir-se no fluxo de processamento. Eventos
estereotipados com indica a localização normal, onde o evento será transmitido para seus ouvintes. Eventos estereotipado com (rich ajax utiliza embora tem
comportamento um pouco diferente) indica quando eventos imediatos são transmitidos. Eventos imediatos são sempre transmitidos antes de seus equivalentes fluxos

3 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

regulares.

3. As setas que partem de cada caixa indicam o próximo passo no ciclo de vida. As três opções possíveis em cada etapa são:

a) Continuar para a próxima etapa.

b) Ir para a fase Render Response, ou

c) Fim do ciclo de vida completo.

As opções a e b são representadas pelas cabeças da seta, e a opção c por um círculo preenchido. É importante notar um detalhe técnico, embora possa parecer que
as opções b e c nunca ocorrem como resultado de processamento de eventos (caixas verdes), na realidade, qualquer código poderia assumir essa responsabilidade,
dentro de um mesmo código (caixa amarela). Além disso, somente a opção a é mostrada na primeira fase e nas caixas de PhaseEvent, ou seja, a última do ciclo de
vida. Ao sair depurando as fases para entender melhor o ciclo de vida, eu percebi que mais cedo ou mais tarde eu irei questionar se é necessário isso tudo, isto é,
questionar a utilidade das outras opções do clico de vida[risos] .

Fase 1: Restore View

Meta para esta fase
Gerar ou recuperar uma árvore de componentes para representar o ponto de vista solicitado, e definir o local a ser utilizado.
Importantes conceitos necessários para compreender esta fase
1. View

Uma página JSP tradicional é referida, em JSF, como um ponto de vista. Isto é apropriado uma vez que uma página JSP constitui a parte do Model-View-Controller
pattern.

2. Component Tree
No JSF, uma View também é conhecida como uma árvore de componentes. Isso também é adequado uma vez que os modelos JSP vejam os elementos de uma página

4 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

JSP (tais como o form, as inputTexts, botões e links) usando objetos Java, onde esses objetos são organizados em uma árvore, com base na hierarquia de
confinamento hierárquica de uma página HTML normal.

3. View Root
Cada componente da árvore está enraizada a um objeto UIViewRoot que é representado pela tag JSF .

4. View Identifier
Cada View/componente de árvore tem um ID único. Quando utilizando JSPs e mapeamento de prefixo, esta é a parte da URL entre o prefixo e a seqüência de
consulta. Ou seja, para uma URL solicitada de http://localhost/myapp/faces/admin/usuario.jsf o id é único /admin/usuario.jsp
Quando utilizamos JSPs e sufixo de mapeamento de extensão, esta parte da URL com a extensão passa a ter. Jsp. Ou seja, para uma URL solicitada de http://localhost
/myapp/admin/usuario.jsf o id também é único /admin/usuario.jsp
Note-se que um identificador da View é um conceito crítico e volta ao estado durante a etapa de navegação da fase Invoke Application.

5. Faces Context
Um FacesContext descreve o ambiente de execução do pedido em andamento. Este é um objeto muito criticado por diversas razões. Ele permite que você
defini/recupera a raiz da View atual afetando assim a View que será exibida para o usuário, que abriga os importantes métodos renderResponse() e
responseComplete() que permitem o ciclo de vida de curto-circuito, e permite o acesso a servlet externo ou contexto portlet, e muito mais.

Atividades Importantes nesta fase

Esta fase trata pedidos da primeira vez de forma diferente (submits de formulário).

Se este é um primeiro pedido para este recurso, ou seja, se a solicitação de entrada leva sem parâmetros, o JSF irá extrair uma visão ID da URL e vai construir uma
marca nova árvore de componentes para ele. Os componentes da árvore são inicializados usando qualquer padrão de valores especificados no JSP. Note que este é o
único momento em que os valores padrão serão usados.

Se o usuário acaba de apresentar uma forma que era anteriormente prestado pelo JSF, então temos um atalho possível. Durante a fase anterior Render Response, JSF
teria poupado esta árvore ou em sessão deste usuário ou em um campo oculto na resposta. A localização real será determinado pelo contexto
javax.faces.STATE_SAVING_METHOD parâmetro definido no web.xml. O JSF, então, quer olhar para a árvore na sessão usando o id da View, ou vai gerar
novamente a partir do campo codificado escondido na resposta. Todos os componentes da árvore têm valores, validadores, conversores, ouvintes e representantes,
que estavam em cursor quando a árvore foi salva durante a última fase Render Response. Se o JSF foi incapaz de recuperar uma árvore previamente armazenada,
ele constrói uma nova marca de árvore usando a exibição de identificação sobre o pedido.

Em ambos os casos, o resultado líquido é uma árvore de componentes que serão utilizados para o processo de solicitação de entrada.
Um par de tarefas domésticas continua. O FacesContext deve ser atualizado para representar corretamente a solicitação atual. Métodos encapsuladores setters são
chamados sobre ele:

a) para definir a recuperação da árvore construída,

b) para definir usuário localidade do estado salvo, desde a localidade padrão (no faces-config.xml) ou,

c) de um cabeçalho sobre o pedido de entrada.

Por um postback, o JSF irá proceder à próxima fase, para um novo pedido, porque não há nenhuma entrada de usuário para processar, então o JSF avança para
Render Response para tornar a árvore com os valores padrão.

5 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

Fase 2: Apply Request Values

Meta para esta fase

Permitir que cada componente da interface do usuário atualize com novas informações a partir da solicitação de entrada.

Importantes conceitos necessário para compreender esta fase

1. Decodificação
Este é o processo pelo qual passa uma peneira no componente por meio de parâmetros de solicitação de entrada de informações que podem afetar seu estado. Ou
seja, o que um componente procura, e como ele atualiza seu estado se é definido por esse componente? Por exemplo, os componentes de entrada esperam para ver
valores atualizados, os botões e links esperam para ver uma indicação para saber se foram clicados e esperam encontrar uma indicação de que eles foram submetidos.

2. Identificador de Componente
Este é o valor atribuído ao atributo id para a tag de um componente. O id do componente deve ser único no seu contêiner de nomeação. Caso contrário a exceção
duplicate id é lançada.

3. Nomeando recipiente
Um contêiner de nomeação é geralmente uma forma (mas pode ser uma subexibição ou uma tabela de dados), e serve como um espaço para os componentes
childrens.

4. Identificador de cliente
Este é o único verdadeiro identificador de um componente, e é composto por nomes de recipiente id e id do componente, delimitado por dois pontos. Note-se que
para um componente que está aninhado dentro de uma hierarquia contêiner de nomeação, por exemplo, uma tabela de dados em um formulário em uma
subexibição, o identificador de cliente pode ficar bastante tempo sem ser executado. Então ele é chamado de identificação do cliente, porque geralmente é usado para
fazer referência a um componente dentro funções Javascript. O id do cliente pode ser absoluto (se ele começa com dois pontos) ou parente. Ele também é usado pelo
UIComponent.findComponent() para localizar um componente quando o cliente identificador é conhecido.

5. Evento UI
Este é um evento que normalmente exibe novamente a página atual depois de fazer algumas mudanças de interface de usuário. Para isso como alternar a exibição de
uma seção? Ou como adicionar/remover itens de uma lista de seleção ou botões de rádio de um grupo? Você normalmente irá querer processamento de curto-circuito
para evitar erros de validação que está sendo exibido para outros campos do formulário.

6. Evento de Aplicação
Este é um evento que chama de transformação apoiada, e é o carro-chefe de sua aplicação. É tratado pelo padrão ActionListener, que chama o método de ação
especificada, e em seguida, chama o padrão NavigationHandler para determinar o fim de ser exibido como o resultado dessa ação.

7. Evento de Ação
Representa quando o usuário clica em um controle de interface de usuário como um botão ou hiperlink.

8. Ação imediata do evento

Esta ação pode ser feita através de um botão ou link cujo atributo imediato é definido como true. Nada mais é do que forçar o que está associado manipulando o botão
a ser invocado logo após que esta fase seja concluída, e após a fase Invoke Application. Um uso comum é implementar um botão Cancelar, o que não deve exigir
que o conteúdo da entrada de outros controles seja validado. Uma vez que o manipulador é executado, JSF automaticamente chama o manipulador de navegação e

6 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

controle de transferências para a fase Render Response.

9. Alterar o valor do evento

Representa que o usuário possa alterar o valor atual de um controle de entrada, como um inputText por exemplo. Essa alteração de valor no cliente só será detectada
quando uma nova conexão com o servidor é estabelecida, por exemplo, quando o usuário envia um formulário, ou através de scripts do lado do cliente que faz uma
apresentação automática.

10. Controle de entrada imediata

Este é um controle de entrada imediata (immediate ou ajaxSingle(lembrando que o ajaxSingle passa por uma fase(se eu não me engano é a fase ActionEvent) para
injetar o valor do capsulador invocado) igual true), cujo atributo é definido como true. Isso força o controle de entrada a ser convertido e validado dentro desta fase, e,
se o valor tiver sido alterado, as suas causas ValueChangeEvent serão invocada logo após que esta fase seja concluída, e também após a fase de processo
validações. Isto é usado para implementar interface de eventos do usuário, ou seja, quando a mesma página deve ser reexibida incorporando todas as alterações
causadas pelo manipulador de eventos, e não outros controles de entrada no formulário precisa ser necessariamente validada nesse momento. Um uso comum é
implementar um checkbox que, quando clicado, alterna a exibição de uma seção do ponto de vista. Note que, diferentemente de manipuladores de eventos de ação,
um valor de manipulador de evento de alteração deve chamar explicitamente o método renderResponse() para passar para a fase Render Response, mas sua
utilidade é questionável pois, caso contrário, as validações ocorrem na fase de validações de processos.

Atividades importantes nessa fase

O JSF permite que cada componente da árvore de componentes atuais a possibilidade de decodificar a solicitação de entrada. Cada componente de procura passa um
parâmetro de solicitação com o mesmo nome do componente cliente identificado. Quando um parâmetro de solicitação correspondente for encontrado, um
componente de entrada define sua propriedade e valor apresentado para o parâmetro de valor, um botão/link irá até fila de um evento de ação, e um formulário irá
definir sua propriedade dos valores submetidos.

Se o controle imediato da propriedade de uma entrada é definido como verdadeiro, ele é convertido/validado e qualquer ValueChangeEvents são chamados no final
desta fase. Se uma propriedade é imediata o ActionSource é true, eventos de ação são chamados, no final desta fase.
Se um manipulador de eventos, conversor, validador ou decode(), ou RenderResponse chamar um método responseComplete(), o ciclo de vida, uma vez
terminado a fase, passa assumir o estado de concluído, e chama o renderResponse(), ou seja, pula para o controle de Render Response, portanto a fase do ciclo de
vida uma vez que esta fase tenha sido concluída. Por exemplo, um erro de conversão/validação de um componente imediato, que re-processa e retorna com uma
mensagem de erro.

Fase 3: Process Validations

Meta para esta fase
Permite que cada componente de entrada da interface do usuário para converter e validar o seu valor extraído da solicitação de entrada.
Importantes conceitos necessário para compreender esta fase

1. Converter
Converte o valor String na entrada do componente que apresentou o valor do atributo para o tipo de dados apropriado para o componente de valor presente.

2. Validator
Aplica-se a regras de validação o valor convertido para um componente.

3. FacesMessage
Representa uma mensagem que precisa ser exibido para o usuário. O FacesContext mantém uma fila de mensagem que contém as mensagens de uma determinada

7 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

visão. A mensagem pode ser geral, aplicável a toda a View, ou pode ser específico para um determinado componente. As mensagens são exibidas para o usuário
usando o ou através das ações.

Atividades importantes nesta fase

Conversão
O JSF primeiro procura um conversor apropriado que ele deve usar para converter o valor String do componente extraído para o tipo de dados de destino (como
definido pelo atributo no bean gerenciado para que este componente esteja acoplado). Ele verifica primeiro com componente renderizador do próximo se parece haver
execução do conversor personalizado, depois se foi anexado a classe, e se esta ação através de seu atributo de conversor ou uma ação de conversores aninhados e,
finalmente, verifica se o conversor foi registrado para o componente-alvo do tipo de dados presente, nesta ordem de precedência. Este mecanismo é mutuamente
exclusivo, ou seja, o primeiro conversor encontrado e usado. Se nenhum conversor foi encontrado em um desses locais, o valor apresentado é deixado intocável.

O conversor é então solicitado, para converter a String para valor apresentado para o tipo de dados de destino.

Se a conversão falhar, ele pede para o componente armazenar a string inválida como seu valor, para que ele possa ser apresentado para o usuário quando a página é
renderizada, sendo assim lançando uma exceção de ConverterException com FacesMessage configurado, do qual é adicionado à fila de mensagens no
FacesContext e define se o componente é válido sentado a propriedade para false. Ai então pula para fase Render Response. Para notificar o usuário de erros de
digitação por exemplo.
Se a conversão for bem-sucedida, o valor convertido é marcado com valor convertido do componente.

É importante notar que os conversores com direito duplo, eles converte Strings para os tipos de dados de destino (como é o caso nesta fase), e converte o alvo de um
tipo de dados String (o que é exigido durante Render Response para escrever a resposta HTML).

Validação
Se a conversão foi bem sucedida para todos os componentes da árvore atual, o JSF pede a cada UIInput para validar esse valor convertido.

Ao contrário da busca de um conversor, a busca de um validador é cumulativa. Ou seja, a validação é delegada a todos os validadores que estão conectados a este
componente, e todos têm que concordar antes que o componente está marcado como sendo válido. Validators pode ser ligado a um componente através de vários
mecanismos. Por exemplo, é necessário atribuir que um componente faz com que um validador implícito seja anexado, então seu atributo validador tem uma ligação
que aponta para um método de validação e validadores podem ser unidos usando < f:validate> e suas acões.
Se qualquer um dos validadores nessa pilha detecta um problema com a conversão de valor do componente, ele vai lançar uma exceção de ValidatorException com
FacesMessage adequado, que é adicionado à fila de mensagens FacesContext, e o componente é marcado como inválido, definindo sua propriedade válida para
false. O JSF, então salta para Render Response para notificar o usuário do erro de validação.
Se o processo de validação for bem sucedido, o valor convertido é marcado como o componente de valor local. Se o valor local mudou, o componente gera também
um ValueChangeEvent.
Se algum manipulador de eventos ou validate() e o método chamado é o responseComplete(), o processamento da solicitação atual é finalizado após até que está
fase esteja concluída, e se chamar renderResponse(), pula para para o JSF Render Response. Dando como concluída esta fase.

Fase 4: Update Model Values

Meta para esta fase
A UI permite que cada componente transfere o seu valor local atualizado para o atributo bean gerenciado ao qual está vinculado.
Importante conceitos necessários para esta fase

8 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

1. Valor vinculativo
A sintaxe Unified Expression da linguagem pode ser usada para definir o atributo de bean para um determinado componente vinculado. Note que a expressão pode
ser de vários níveis de profundidade, isto é, se uma propriedade se referência ao encapsulador de um bean, entre outras.

Atividades importantes nessa fase

Os Beans são ligados aos componentes através de expressões EL JSF. Essas expressões são geralmente o valor de expressões que indicam uma ligação do bean
gerenciado em um dos escopos servlet, e um encapsulador setter que referencia a propriedade desejada para que o valor seja transferido.
Se a atualização falhar, uma mensagem entra na fila do FacesContext.addMessage(), e do componente é marcada como inválida. Em seguida, pula para Render
Response para notificar o usuário de erros de digitação.

Fase 5: Invoke Application

Meta para esta fase
Executa aplicações específicas de processamento de costume e determina o ponto de vista próximo a ser exibido para o usuário. Aqui é ponto crucial da sua aplicação,
pois este é o coração da sua lógica de aplicação.

Importantes conceitos necessários para compreender esta fase

1. ActionListener
Um componente de comando (um botão ou um link) pode ser associado com manipuladores via (em ordem de preferência) o atributo de ação, seu atributo
ActionListener, ou através de ações ActionListener aninhadas. Todos esses ouvintes de ação serão invocados quando o componente é clicado. A ação do atributo
obrigatório é especial na medida em que é tratado pelo padrão JSF ActionListener que também chama o padrão NavigationHandler para navegar para a próxima
exibição. O ActionListener de ligação é especial, pois ele permite que você acessa o componente que disparou o evento. As ações ActionListener aninhados são
especiais porque permitem ligar vários ouvintes de ação para um determinado componente.

Atividades importantes neste fase

Agora que os backing beans e os objetos do modelo são up-to-date, transmissões JSF o ActionEvent da fila é reponsável por chamar os ouvintes de ação registrados
para cada componente. Este é um ponto seguro no qual podem invocar esses ouvintes, do que por exemplos os outros componentes na árvore ter pegado e validado
os seus valores. Note que os ouvintes de eventos de ação imediata são notificados no início do ciclo, porque eles são projetados para lidar com eventos que vão pular a
fase de validação, tal como foi explicado no cenário do botão Cancelar.
Para um método de ação obrigatória, após a ouvintes de ação são chamados, o ouvinte ação padrão chama o NavigationHandler para escolher a próxima página.
Se nenhum método de ação é registrado, o ouvinte ação padrão simplesmente reexibe a exibição atual.

Fase 6: Render Response

Meta para esta fase
Nesta fase a árvore de componentes agora é processada como HTML.
Importantes conceitos necessários para esta fase

1. Enconding
Este é o processo de pedir para cada componente para gravar o seu valor para a resposta. O componente pode delegar esta tarefa a seu processador de associados, e
também podem invocar um conversor associado ao converter o tipo de dados nativo para fora, ou para uma String que será enviada para o navegador do usuário.

2. State saving
Este é o processo de desidratação da árvore de componentes de modo que possa ser hidratado e voltar a existir mais tarde.

9 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

Atividades importantes nesta fase

Neste momento, estamos fazendo um tratamento específico com todos os aplicativos e tudo que resta para ser serializado na árvore de componentes fora do domínio
HTML que será enviada de volta para o cliente, e essa tarefa é realizada por uma classe chamada javax.faces.lifecycle.ViewHandler. Todas as implementações JSF
deve vir com um padrão que pode codificar ViewHandler JSPs. No entanto, você pode trocar isso por uma aplicação personalizada (como o que vem com o Facelets
que pode codificar arquivos XHTML).
A árvore corrente do atual estado (incluindo a estrutura da árvore) é, então, guardada na própria solicitação ou no servidor (escopo de sessão). Você escolhe o local,
através do contexto javax.faces.STATE_SAVING_METHOD parâmetro definido no web.xml, que pode ser definido como um cliente ou servidor.
Quando o estado for salvo do lado do cliente, o estado verifica se o objeto foi realmente serializado como um campo de formulário oculto codificado dentro da execução
do carregamento de resposta. Ai sim o cliente retorna com o seu próximo pedido.

Quando o estado é salvo no lado do servidor, o mesmo estado é visualizado e guardado na sessão do usuário no servidor.
Como esperado, o "trade off" aqui é entre o consumo de memória no servidor e os tempos de resposta/largura de banda em uma conexão de rede. Ai então você deve
começar a se preocupar em economizar o espaço no lado do servidor e, em seguida, mudar para o lado do cliente somente se você tiver problemas com o uso de
memória.

Conclusão
Como tinha dito o ciclo de vida do JSF não é trivial. O JSF lhe fornece várias opções de escolha, e que dependendo da escolha pode ser assustadora e codificação fica
um lixo. No entanto, essa complexidade é aliviada pelo fato de:

a) Que lida automaticamente com um monte de coisas que são tediosa de se implementar, te livrando da vários controles e configurações que o framework te
possibilita;

b) As implementações padrão dos ViewHandler, ActionListener, NavigationListener, são adequados para a maioria dos propósitos para que você raramente tem
que escrever de forma mais personalizada;

c) E Você pode ignorar tranquilamente um monte de caso de funcionalidade de ponta, como ouvinte de classes de ação e os eventos de alteração de valor, para a
maioria das coisas "medíocres" que ocorrem nas aplicações.

Baixar: fasesJSF.jpg
Tamanho: 60 KB
comentários: 0

Home Sobre Anuncie RSS Notícias

RSS Fórum
O JavaFree.org é uma comunidade java formada pela coolaboração dos desenvolvedores da tecnologia java. A
publicação de artigos além de ajudar a comunidade java, ajuda a dar maior visibilidade para o autor. Contribua conosco.

JavaFree é um site do Grupo DevMedia

10 de 11 11/11/2010 09:29
JSF ciclo de vida - Java Free.org http://javafree.uol.com.br/artigo/878298/JSF-clico-de-vida.html

www.devmedia.com.br | www.javafree.org | www.mrbool.com |

11 de 11 11/11/2010 09:29