Quando um usuário visualiza uma Página do Visualforce, as instâncias da Controller e Components associados à página são criados pelo servidor do Salesforce. A ordem em que esses elementos são executados pode afetar a forma como a página é exibida para o usuário. Por isso é importante entendermos exatamente como funciona o ciclo de vida de uma Página Visualforce e assim, tirar o melhor proveito disso, vamos lá?

Entendendo o Ciclo de Vida de uma Página Visualforce

Para entender completamente o funcionamento de uma Página Visualforce e execução dos elementos dela, você deve primeiro entender o ciclo de vida de uma Página Visualforce. Isto é, como a página é criada e destruída ao longo de uma sessão de usuário. O ciclo de vida de uma página é determinado não apenas pelo conteúdo da página, mas também pela forma como a página foi solicitada. Existem dois tipos de solicitações de página do Visualforce:

  • Uma é a requisição GET, é uma solicitação inicial para uma página feita quando um usuário entra em uma URL ou quando o usuário clica em um link que leva a uma nova página.
  • E a requisição Postback, é feita quando a interação do usuário requer uma atualização de página, como quando um usuário clica em um botão Salvar e isso dispara uma ação Salvar na sua Controller.
Para detalhes específicos dos dois tipos de solicitações, iremos ilustram o ciclo de vida de uma Página Visualforce e também algumas dicas sobre como lidar com a ordem de execução ao escrever suas próprias Controllers e Components.

Requisição GET

Ciclo de Vida de uma Página Visualforce - Requisição GET

No diagrama acima, o usuário inicialmente solicita uma página, inserindo a URL no navegador ou clicando em um link ou botão que leva a uma Página Visualforce. Este pedido de página inicial é chamado de Requisição GET.

  1. Os métodos do construtor na Controller e classes de Componentes são chamados, instanciando os objetos da Controller.
  2. Se a página contiver componentes personalizados, eles serão primeiramente criados e os métodos do construtor da Controller e do Componente serão executadas. Se os componentes tiverem atributos, esses serão preenchidos após a execução dos construtores.
  3. A página então preenche os atributos dos componentes e em seguida é executa o método Action se o memo estiver definido no atributo da <apex: page> em seguida todas as outras chamadas de método, como GET e SET, são realizadas.
  4. Se a página contiver um componente <apex: form>, todas as informações necessárias para manter o estado do banco de dados entre as solicitações de página são salvas como uma ViewState criptografada. A ViewState é atualizado sempre que a página é atualizada.
  5. O HTML resultante é enviado para o navegador. Se houver tecnologias do lado do cliente na página, como o JavaScript, cabe então ao navegador fazer tais execuções.

Uma vez que um novo pedido de requisição get é feito pelo usuário, os objetos da ViewState e os objetos da Controller são eliminados.

Se o usuário é redirecionado para uma página que usa a mesma Controller e o mesmo ou um subconjunto de componentes, então uma solicitação de envio é feita, e o ViewState é mantida. 

Requisição postback

Uma requisição postback é feita quando a interação do usuário requer uma atualização de página, como quando um usuário clica em um botão Salvar que desencadeia uma ação salvar na sua Controller. O diagrama a seguir mostra como uma página do Visualforce interage com uma Controller e seus componente, durante uma requisição postback:

Ciclo de Vida de uma Página Visualforce - Request postback

  1. Durante uma requisição postback, a ViewState é decodificada e é usada como base para atualizar os valores na página.

Um componente com o atributo imediate setado como true ignora a fase do pedido. Em outras palavras, a ação é executada, mas nenhuma validação é realizada nas entradas e nenhuma mudanças de dados na página é realizada.

2. Depois que a ViewState é decodificada, as propriedades são populadas e os métodos definidos na controller, incluindo também a execução dos métodos definidos nas controllers dos componentes.

Essas chamadas de método não atualizam os dados, a menos que todos os métodos sejam executados com sucesso. Por exemplo, se um dos métodos atualiza uma propriedade e a atualização não é válida devido a regras de validação ou a um tipo de dados incorreto, os dados não são atualizados e a página é exibida novamente com as mensagens de erro apropriadas.

3. A ação que desencadeou a requisição postback foi executada. Se essa ação for concluída com sucesso, os dados serão atualizados. Se a requisição postback retornar o usuário para a mesma página, então a ViewState é atualizada.

Se a sua <apex:page> contiver um atributo Action, ao executar essa ação as propriedades da sua controller não são preenchidas, o preenchimento só ocorre durante uma requisiçao Get.

4. O HTML resultante é enviado para o navegador.

Se o postback forçar um redirecionamento para uma página que utiliza a mesma controller da página de origem então todos os dados da ViewState serão mantidos, caso o redirecionamento seja para uma págia que contém uma controller diferente, então uma requisição Get será realizada. Se o pedido de envio tiver um componente <apex:form>, então apenas o parâmetro de consulta Id da requisição é retornado.

Você pode usar o atributo setRedirect em um PageReference para controlar se uma solicitação de postback ou get será executada. Se o valor do setRedirect for definido como verdadeiro, uma solicitação get será executada. Configurando-o como falso não ignora a restrição de que uma requisição de postback será executada se e somente se o alvo usar a mesma controller da página de origem. E se setRedirect estiver definido como falso, e o alvo não atende a esses requisitos, um pedido de get será feito.

 

Bom, espero que tenho clareado um pouco mais a sua visão sobre o ciclo de vida de uma página visualforce, e em breve escreverei em mais detalhes sobre o ViewState, pois apesar de ser um artificio poderoso das páginas visualforcse, também pode ser o calcanhar de Aquiles da sua aplicação.

 

Recomendo que você faça o Trailhead sobre Visualforce, lá você encontrará em detalhes e exemplos técnicos de como trabalhar com Visualforces, se você ainda não iniciou o seu Trailhead, sugiro que de uma olhada nesse post, onde falo um pouco do porque você deve começar agora mesmo.

Dúvidas, comentários, críticas ou elogios, utilize o campo de comentários abaixo, um forte abraço e até o próximo post :)

Fernando Sousa

Fernando Sousa

Senior Salesforce Developer at Check21.com

Bacharel em Sistemas da Informação pela Universidade de Taubaté (UNITAU) e MBA em Projeto de Aplicações para Dispositivos Móveis pelo IGTI – Instituto de Gestão em Tecnologia da Informação.

Comecei a programar bem cedo, por volta de 10 anos de idade, de maneira auto-didata passei por várias linguagens.

Em 2015 conheci a Salesforce, fazendo integração entre Salesforce Platform e um Aplicativos Mobile,

Atualmente possuo as certificações Salesforce Certified Platform Developer I, Salesforce Certified Platform App BuilderSalesforce Certified Platform Developer IISalesforce Administrator.

Com mais de 100 emblemas e 50.000 pontos no trailhead, conquistei o título de Ranger.

Acompanhe meu Trailhead aqui.

Pin It on Pinterest

Shares