Explorar o contêiner do aplicativo Visualforce
Objetivos de aprendizagem
Após concluir esta unidade, você estará apto a:
- 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
A maior diferença entre o Visualforce no Lightning Experience e o Visualforce no Salesforce Classic é o ambiente em que ele é executado. No Salesforce Classic, o Visualforce “domina” a página, a solicitação, o ambiente. O Visualforce é o contêiner de aplicativos. Mas no Lightning Experience, o Visualforce é executado em um iframe que está encapsulado dentro do contêiner maior do Lightning Experience.
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
Vamos começar com o contêiner externo, o aplicativo Lightning. O contêiner Lightning é um “aplicativo de página única”, ou SPA, que pode ser acessado no URL /lightning. A página /lightning é carregada, seu código é iniciado e o código do aplicativo toma conta do ambiente.
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
Quando sua página do Visualforce é executada no Lightning Experience, ela é exibida dentro de um iframe de HTML. Um iframe cria um contexto de navegação integrado que funciona eficientemente como uma “janela” de navegador separada do contexto de navegação principal do Lightning Experience. O iframe cria um limite entre a página do Visualforce e seu pai, o aplicativo Lightning Experience.
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
Os efeitos do novo contêiner do Visualforce, que integram a página do Visualforce em um iframe dentro do aplicativo do Lightning Experience, podem ser amplamente divididos em duas categorias que chamaremos de segurança e escopo.
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
Os elementos de segurança que podem ser afetados incluem.
- 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
Quando falamos sobre escopo, estamos falando principalmente sobre os seguintes tipos de coisas.
- 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
Quando as suas páginas do Visualforce são executadas no Lightning Experience uma série de mudanças de baixo nível acontece nos bastidores. Essas mudanças permitem que a maioria das páginas “simplesmente funcionem” no contêiner do Lightning Experience e, por vezes, você pode dar-se por satisfeito por elas estarem lá. Mas ainda assim vai querer saber que elas estão funcionando, principalmente quando você está trabalhando nos fluxos de aplicativos avançados ou solucionando um problema complicado.
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
Esses atributos afetam o cabeçalho e a barra lateral do Salesforce Classic nas páginas do Visualforce. O cabeçalho e a barra lateral do Salesforce Classic são sempre suprimidos quando as páginas são executadas no Lightning Experience, a favor dos elementos de navegação do Lightning Experience. Não há atributos correspondentes que afetem o cabeçalho ou a barra lateral do Lightning Experience porque eles não podem ser suprimidos.
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
Embora o sforce.one soe como um androide que trabalha na cantina do Salesforce*, realmente ele é um objeto utilitário que fornece uma série de funções úteis que podem ser usadas no seu código JavaScript próprio.
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