Explorar o contêiner do aplicativo Visualforce
Objetivos de aprendizagem
- Descrever três diferenças entre as páginas do Visualforce em execução no Salesforce Classic em comparação com as mesmas páginas em execução no Lightning Experience.
- Descrever dois padrões de código comuns que precisam de atualização para funcionar no Lightning Experience.
- Listar duas alterações a valores padrão da página do Visualforce quando executada no Lightning Experience.
Explorando o contêiner do aplicativo Visualforce
Essa mudança no contexto de execução tem inúmeros efeitos na forma como as páginas do Visualforce podem afetar o aplicativo Salesforce como um todo. Nesta unidade falaremos sobre essas mudanças, mas os detalhes completos de algumas delas ficarão para suas respectivas unidades.
Esta unidade está um pouco mais “em construção” do que o restante. O motivo é simples: O impacto dos problemas descritos aqui é altamente dependente do seu código. Temos trabalhado arduamente para fazer com que, de sua perspectiva, as coisas “simplesmente funcionem” e, na maioria dos casos, pouco ou nada daqui aparecerá em seu radar. No entanto, não podemos prever todas formas de usar o Visualforce. Estamos aqui descrevendo os aspectos gerais de como o Lightning Experience afeta o Visualforce. À medida que conversarmos mais com você e recebermos mais informações suas no que se refere ao impacto real, poderemos dar explicações com mais detalhes sobre como abordar questões específicas.
O contêiner externo do Lightning
O processo pelo qual um aplicativo de página única carrega seus recursos, normalmente um shell estático HTML e muito JavaScript, é ao mesmo tempo interessante e complexo. Se você já trabalhou com estruturas em JavaScript, como AngularJS ou React, está razoavelmente familiarizado com as noções básicas de como o Lightning inicia na forma de /lightning. E, para ser sincero, os detalhes minuciosos não interessam. Você não tem controle sobre ele e a implementação continua a evoluir.
Isto é o que você precisa saber: O Lightning Experience, ou /lightning, é responsável pela solicitação. A página do Visualforce, não. Sua página precisa trabalhar com as restrições impostas a ela pelo Lightning Experience. O Lightning Experience é o contexto principal e a página do Visualforce é o contexto secundário. Filhos precisam obedecer aos seus pais.
Algumas dessas restrições, como o tamanho do quadro em que a página do Visualforce é exibida, são impostas diretamente pelo Lightning Experience. Elas são mais fáceis de entender e de trabalhar. Falaremos sobre elas daqui a pouco.
Outras restrições são implícitas e impostas não pelo Lightning Experience, mas pelo navegador que o executa. Elas são basicamente restrições de segurança e de execução do JavaScript. A maioria das páginas não é afetada por essas restrições de segurança, e as que são falham logo e exibem mensagens de erro claras. Os erros de JavaScript são mais difíceis de se perceber e diagnosticar, mas existem algumas regras gerais que vamos mostrar em breve.
Iframe do Visualforce
A vantagem de executar as páginas do Visualforce dentro de um iframe é que, para as páginas que não precisam acessar ou alterar o contexto de navegação de nível superior, a execução dentro do iframe é quase igual à execução de uma página no Salesforce Classic. É por isso que não é necessário modificar todas as suas páginas do Visualforce para adaptá-las ao altamente diferente ambiente de solicitação de segundo plano do Lightning Experience. É uma parte importante da estratégia “simplesmente funciona” de suporte do Visualforce.
É claro que o lado ruim é que as páginas que precisam sim acessar o contexto de navegação de nível superior devem alterar algumas coisas. Falaremos mais especificamente sobre isso na próxima seção.
Se sua página está se comunicando com serviços além do Salesforce, o limite do iframe também pode resultar em uma necessidade de atualização das configurações de CORS da sua organização, configurações remotas do site, configurações de clickjack ou da política de segurança do conteúdo. Como isso depende das políticas de segurança e configurações fora do Salesforce, não podemos fornecer uma receita de mudanças específicas. Nós apenas alertamos aqui.
Impacto do novo contêiner
Queremos frisar novamente que muitas das páginas do Visualforce (ou até a maior parte delas) não serão afetadas por estas questões. No caso de haver alguma página afetada, seguimos o lema “mais vale prevenir que remediar”. Se já tivermos falado sobre esse assunto, a origem do problema será identificada mais rapidamente.
Impacto na segurança
- Renovação e manutenção da sessão
- Autenticação
- Solicitações entre domínios
- Restrições de integração
Já falamos resumidamente sobre alguns desses elementos, em relação aos itens que tratam das solicitações entre domínios. Ou seja, quando o conteúdo na janela completa do navegador provém de solicitações para diferentes servidores e serviços, é provável que algumas dessas solicitações tenham dificuldades em serem exibidas em um contexto para o qual elas não estão preparadas. Sua missão, caso haja necessidade, é a de preparar esses serviços para lidar com as solicitações que devem ser reunidas no contexto do Lightning Experience. Como dissemos anteriormente, os detalhes variam; por isso, não podemos fornecer respostas específicas aqui.
Uma coisa que queremos especialmente mencionar é a manutenção da sessão. No caso dos nossos atuais objetivos, uma “sessão” significa basicamente algum tipo de token que seu navegador reutiliza em todas as solicitações para que você não precise digitar seu nome de usuário e sua senha para cada solicitação. Muitas vezes, você precisa acessar a sessão atual usando a variável global $Api.Session_ID.
Veja o que você precisa se lembrar. $Api.Session_ID retorna valores diferentes, dependendo do domínio da solicitação. Isso ocorre porque o ID da sessão varia durante uma sessão sempre que você cruza um limite de nome de host, como do .salesforce.com para o force.com. Normalmente, o Salesforce lida de forma transparente com a passagem de sessão entre domínios. Porém, se você está passando o ID da sessão por conta própria, esteja ciente de que pode ser necessário acessar $Api.Session_ID novamente a partir do domínio à direita para assegurar um ID de sessão válido.
As páginas do Lightning Experience e do Visualforce não são apenas mantidas em diferentes contextos do navegador; elas também vêm de diferentes domínios. Portanto, apesar de tudo estar sendo exibido em uma janela do navegador, o ID da sessão dentro do iframe do Visualforce será diferente do ID da sessão fora do iframe, em outra parte do Lightning Experience. O Salesforce e o Lightning Experience lidam com isso de forma transparente no uso normal. Mas, se você estiver usando o ID da sessão como um mecanismo de arranque (o que, geralmente, não é uma boa ideia), talvez seja necessário analisar a forma como você está lidando com isso.
Impacto no escopo
- Modificação e acesso do DOM
- Acesso, visibilidade e escopo do JavaScript
- Variáveis globais do JavaScript, como window.location
Se esta lista parece complicada e confusa, não se preocupe, podemos resumir tudo a algo simples e fácil de lembrar: Não toque naquilo que é dos outros. Especificamente, seu código JavaScript (e as regras de folhas de estilo, neste caso), pode afetar os elementos (nós do DOM, variáveis JavaScript, etc.) em seu contexto de navegação de página, mas não pode acessar os elementos de outro contexto de navegação, como o contexto Lightning Experience pai. Não toque em coisas com outros contextos!
Em termos práticos, o padrão de código mais comum para fazer esse tipo de coisa seria manipular window.location para navegar para outra página. Essa é uma ação tão comum e já escrevemos mais detalhes sobre esta questão específica... Bem, prometemos que, quando você terminar este módulo, já estará cansado de ouvir sobre isso.
Uma última observação. Se você é um desenvolvedor experiente de JavaScript, deve estar pensando que sabe lidar com problemas do tipo “Não tenho acesso ao contexto de navegação pai” usando contentWindow, window.parent ou qualquer coisa semelhante. Esqueça. É provável que você se depare com a mesma política de origem (Visualforce e Lightning Experience vêm de domínios distintos, lembra-se?). E, mesmo que este não seja o caso, você provavelmente substituirá bugs de bloqueio óbvios por pequenos bugs intermitentes. Onde você deseja usar o seu tempo: Fazendo as coisas corretamente ou no depurador?
Fazer a coisa certa significa chamar APIs disponíveis nas suas páginas do Visualforce, principalmente para navegação. Se você realmente precisar de alterar coisas que ultrapassem os limites da janela, use window.postMessage para enviar uma mensagem para receber o código em outra janela.
Os padrões e o ambiente do Visualforce mudam no Lightning Experience
Algumas dessas mudanças são simples e óbvias quando se pensa nelas. Por exemplo, as páginas do Visualforce que são executadas no Lightning Experience sempre apresentam o cabeçalho e a barra lateral padrão do Salesforce Classic suprimidos. Outras mudanças não são tão visíveis, mas têm um impacto igualmente grande.
Os atributos <apex:page> showHeader e sidebar são sempre false
Se sua página for compartilhada entre o Salesforce Classic e o Lightning Experience, você ainda pode definir esses atributos para os valores que gostaria de usar quando a página for executada no Salesforce Classic.
O atributo standardStylesheets de <apex:page>, que determina se as fichas de estilo padrão do Salesforce Classic devem ser incluídas ou suprimidas, não é afetado pelo Lightning Experience. Ou seja, o padrão é true no Lightning Experience, mas você pode alterá-lo.
O objeto utilitário JavaScript sforce.one
O sforce.one é automaticamente injetado em sua página quando executado no Lightning Experience ou no aplicativo Salesforce. Você vai vê-lo no seu console do depurador JavaScript e na lista de recursos para desenvolvedores web. Não é necessário fazer nada para adicioná-lo e também não há nenhuma maneira de suprimi-lo. (Infelizmente, não há nenhuma maneira de ter o sforce.one nas suas páginas do Visualforce no Salesforce Classic.)
O sforce.one é usado principalmente para disparar eventos de navegação. Os detalhes completos podem ser conferidos em outra unidade: Como gerenciar a navegação.
____________________
* Não existe nenhuma cantina no Salesforce. Que pena!
Recursos
- Modify Session Security Settings
- Visualforce Developer’s Guide
- Rede de Desenvolvimento da Mozilla: HTML Inline Frame Element (<iframe>)
- Rede de Desenvolvimento da Mozilla: Using Content Security Policy
