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.
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.
- Os métodos do construtor na Controller e classes de Componentes são chamados, instanciando os objetos da Controller.
- 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.
- 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.
- 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.
- 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:
- 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
Senior Salesforce Developer
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 me conectei a plataforma Salesforce pela primeira vez, para fazer una integração entre um Aplicativos Mobile em android e o Salesforce Platform.
Atualmente com as certificações Salesforce Certified Platform Developer I, Salesforce Certified Platform App Builder, Salesforce Certified Platform Developer II, Salesforce Administrator e Sharing and Visibility.
Acompanhe meu Trailhead aqui.