Explorar el contenedor de aplicaciones de Visualforce
Objetivos de aprendizaje
Después de completar esta unidad, podrá:
- Describir tres diferencias entre páginas de Visualforce que se ejecutan en Salesforce Classic en comparación con las mismas páginas que se ejecutan en Lightning Experience.
- Describir dos patrones de código comunes que necesitan actualizarse para funcionar en Lightning Experience.
- Enumerar dos cambios en los valores predeterminados de páginas de Visualforce cuando se ejecutan en Lightning Experience.
Exploración del contenedor de aplicaciones de Visualforce
La mayor diferencia entre Visualforce en Lightning Experience y Visualforce en Salesforce Classic es el entorno en el que se ejecuta. En Salesforce Classic, Visualforce “posee” la página, la solicitud, el entorno. Visualforce es el contenedor de aplicaciones. Pero en Lightning Experience, Visualforce se ejecuta fuera de un iframe que está envuelto en el contenedor Lightning Experience de mayor tamaño.
Este cambio en el contexto de ejecución tiene un número de efectos sobre la forma en que las páginas de Visualforce pueden afectar a la aplicación Salesforce completa. Trataremos esos cambios en esta unidad, pero se dejarán los detalles completos de algunos de ellos para sus propias unidades.
Esta unidad está un poco más “en construcción” que el resto. La razón es sencilla: La repercusión de los problemas descritos aquí depende en gran medida de su código. Hemos trabajado muchísimo para hacer que las cosas “simplemente funcionen” para usted, y en la mayoría de los casos aparecerá poco o nada en su radar. Pero no podemos prever todas las formas de uso de Visualforce. Aquí estamos esbozando algunos aspectos generales sobre cómo Lightning Experience afecta a Visualforce. Cuando tiene pláticas con nosotros y a medida que aprendamos más de usted sobre la repercusión real, podemos ofrecer explicaciones con más detalles sobre la forma de solucionar problemas específicos.
El contenedor exterior de Lightning Experience
Comencemos con el contenedor exterior, la aplicación Lightning Experience. El contenedor de Lightning Experience es una “aplicación de página única” o SPA, al que se accede en la dirección URL /lightning. La página /lightning se carga, su código se inicia, y ese código de aplicación toma el control del entorno.
El proceso por el cual una aplicación de página única carga sus recursos, normalmente un shell HTML estático y gran cantidad de JavaScript, es interesante y complejo a partes iguales. Si ha trabajado con marcos de trabajo JavaScript como AngularJS o React, estará bastante familiarizado con los fundamentos de cómo Lightning Experience, en la forma de /lightning, se inicia. Y para ser honestos, los detalles completos no son relevantes. Usted no tiene el control, y la implementación sigue evolucionando.
Esto es lo que es importante que sepa: Lightning Experience, o /lightning, está a cargo de la solicitud. No es el caso de su página de Visualforce. Su página tiene que funcionar con las restricciones que Lightning Experience le impone. Lightning Experience es el contexto principal, y su página de Visualforce es el contexto secundario. El contexto secundario tiene que obedecer al principal.
Algunas de estas restricciones, como el tamaño del marco en el que se visualiza su página de Visualforce, vienen impuestas directamente por Lightning Experience. Son más sencillas de comprender y de trabajar con ellas, y las trataremos en un minuto.
Otras restricciones son implícitas, y no vienen impuestas por Lightning Experience sino por el navegador que las ejecutan. Estas son mayormente restricciones de seguridad y JavaScript. La mayoría de las páginas no están afectadas por estas restricciones de seguridad, y aquellas que lo están normalmente fallan de forma temprana con mensajes de error claros. Los errores de JavaScript son más difíciles de descubrir y diagnosticar, pero hay algunas reglas generales que trataremos dentro de poco.
El iframe de Visualforce
Cuando su página de Visualforce se ejecuta en Lightning Experience, se muestra dentro de un iframe HTML. Un iframe crea un contexto de navegación incrustado que separa de forma efectiva una “ventana” del navegador del contexto de navegación principal de Lightning Experience. El iframe crea un límite entre la página de Visualforce y su principal, la aplicación Lightning Experience.
La ventaja de ejecutar páginas de Visualforce dentro de un iframe es que, para páginas que no necesitan acceder o cambiar el contexto de navegación de nivel superior, la ejecución dentro del iframe tiene la apariencia casi exacta a la ejecución de un página en Salesforce Classic. Esta es la razón por la que no necesita modificar todas sus páginas de Visualforce para adaptarlas al entorno de solicitudes altamente diferente de Lightning Experience. Es una parte importante de la estrategia “simplemente funciona” para dar cobertura a Visualforce.
La otra cara de la moneda es, por supuesto, que en las páginas que sí necesitan acceder al contexto de navegación de nivel superior hay que cambiar algunas cosas. Trataremos algunos aspectos específicos en la siguiente sección.
Si su página se comunica con servicios a parte de Salesforce, el límite del iframe también podría dar como resultado la necesidad de actualizar los parámetros de CORS, la configuración de sitios remotos, la configuración de la protección contra secuestro de clics, o bien las políticas de seguridad de contenidos de su organización. Ya que estos elementos dependen de las políticas y configuraciones de seguridad fuera de Salesforce, no podemos proporcionar una receta para realizar cambios específicos. Simplemente lo avisamos aquí.
Repercusión del nuevo contenedor
Los efectos del nuevo contenedor de Visualforce, que incrusta la página de Visualforce en un iframe dentro de la aplicación Lightning Experience, puede dividirse ampliamente en dos categorías, que llamaremos seguridad y ámbito.
De nuevo queremos enfatizar: muchas, o incluso la mayoría de las páginas de Visualforce no se verán afectadas por estos problemas. Pero para aquellas que sí lo están, pensaremos “hombre prevenido vale por dos”. Encontrará el origen del problema más rápidamente si ya hablamos de él con anterioridad.
Repercusión sobre la seguridad
Los elementos de seguridad que pueden verse afectados incluyen los siguientes:
- Mantenimiento y renovación de sesiones
- Autenticación
- Solicitudes entre dominios
- Restricciones de incrustación
Ya hemos tratado algunos de ellos de forma breve, los elementos relacionados con las solicitudes entre dominios. O sea, cuando el contenido en la ventana de navegador completa proviene de solicitudes de servidores y servicios diferentes, existe la posibilidad de que cualquiera de esas solicitudes se vea obstaculizada al mostrarse en un contexto para el que no está preparada. Su misión, si surgiera la necesidad, es la de preparar esos servicios para que controlen las solicitudes dirigidas a estar reunidas en el contexto de Lightning Experience. Como dijimos antes, los detalles varían, así que no podemos aportar aquí respuestas específicas.
Una cosa que sí hay que mencionar de forma específica es el mantenimiento de las sesiones. Una “sesión” para nuestro propósito es básicamente un tipo de token que su navegador reutiliza de solicitud a solicitud de modo que no es necesario ingresar su nombre de usuario y contraseña para cada solicitud. A menudo necesita acceder a la sesión actual empleando la variable global $Api.Session_ID.
Algunas cosas a tener en cuenta: $Api.Session_ID devuelve valores diferentes dependiendo del dominio de la solicitud. Esto se debe a que el Id. de sesión varía durante una sesión siempre que cruza los límites de un nombre de host, como .salesforce.com a .force.com. Normalmente, Salesforce controla de forma transparente el intercambio de sesiones entre dominios, pero si está pasando el Id. de sesión usted mismo, tenga en cuenta que puede que sea necesario volver a acceder a $Api.Session_ID desde el dominio correcto para garantizar un Id. de sesión válido.
Las páginas de Lightning Experience y Visualforce no solo se mantienen en contextos de navegador diferentes, también provienen de dominios diferentes. De este modo, aunque todo se muestra en una ventana de navegador, el Id. de la sesión dentro del iframe de Visualforce será diferente al del Id. de la sesión fuera del iframe, en otra parte de Lightning Experience. Salesforce y Lightning Experience tratan esto de forma transparente en un uso normal. Pero si está pasando el Id. de sesión como los entremeses de una fiesta (normalmente no es buena idea), es posible que tenga que revisar cómo lo está haciendo.
Repercusión sobre el ámbito
Cuando hablamos sobre el ámbito, nos referimos principalmente a los siguientes tipos de cosas.
- Acceso y modificación de DOM
- Ámbito, visibilidad y acceso de JavaScript
- Variables globales de JavaScript como window.location
Si esta lista parece complicada o confusa, no se preocupe, la podemos reducir a algo sencillo y fácil de recordar: No toque las cosas de los demás. En particular, su código JavaScript (y reglas de hojas de estilos para ese asunto) puede afectar a elementos (nodos DOM, variables de JavaScript, etcétera) en el contexto de navegación de su página, pero no puede acceder a elementos de otro contexto de navegación, como el contexto principal de Lightning Experience. ¡No toque las cosas de otro contexto!
Siendo prácticos, el patrón de código más habitual donde desearía hacer este tipo de cosa es manipular window.location para navegar a otra página. Es una cosa tan común de hacer que hemos redactado los detalles sobre este problema específico... bueno, para cuando termine este módulo, estará harto de oírlo, se lo prometemos.
Una última nota. Si es un desarrollador de JavaScript con experiencia, probablemente ya habrá estado pensando que sabe cómo tratar los problemas con “No tengo acceso al contexto de navegación principal” empleando contentWindow, window.parent o similares. Le rogamos que no lo haga. Probablemente se verá envuelto en políticas del mismo origen (Visualforce y Lightning Experience se sirven desde dominios diferentes, ¿recuerda?). Incluso en caso contrario, probablemente sustituirá fallos obvios que entorpecen con fallos sutiles intermitentes. ¿Dónde desea emplear su tiempo? ¿Haciendo las cosas bien o en el depurador?
Hacer las cosas bien significa llamar a las API que tiene a su disposición en sus páginas de Visualforce, principalmente para la navegación. Si realmente necesita afectar a elementos entre límites de marcos, utilice window.postMessage para enviar un mensaje para recibir código en otro marco.
Cambios en los valores predeterminados y en el entorno de Visualforce en Lightning Experience
Cuando sus páginas de Visualforce se ejecutan en Lightning Experience, se produce un número de cambios de bajo nivel en segundo plano. Estos cambios permiten a la mayoría de las páginas que “simplemente funcionen” en el contenedor de Lightning Experience, y a veces hay que alegrarse de que estén ahí. Si aún desea saber lo que está ocurriendo, especialmente cuando está trabajando en flujos de aplicación avanzados o solucionando un problema complicado.
Algunos de estos cambios son sencillos y obvios una vez que se analizan. Por ejemplo, a las páginas de Visualforce que se ejecutan en Lightning Experience siempre se les suprime el encabezado y la barra lateral de Salesforce Classic. Otros cambios no son tan visibles, pero tienen una gran repercusión.
Los atributos <apex:page> showHeader y sidebar son siempre falsos
Estos atributos afectan al encabezado y la barra lateral de Salesforce Classic en las páginas de Visualforce. El encabezado y la barra lateral de Salesforce Classic siempre se suprimen cuando las páginas se ejecutan en Lightning Experience, en favor de los elementos de navegación de Lightning Experience. No hay atributos correspondientes que afecten al encabezado y la barra lateral de Lightning Experience porque no pueden suprimirse.
Si su página está compartida entre Salesforce Classic y Lightning Experience, aún podrá establecer estos atributos o los valores que le gustaría utilizar cuando la página se ejecuta en Salesforce Classic.
El atributo standardStylesheets de <apex:page>, que determina si incluir o suprimir las hojas de estilo estándar de Salesforce Classic, no se ve afectado por Lightning Experience. O sea, que toma true como predeterminado en Lightning Experience, pero no se puede cambiar.
El objeto de utilidad sforce.one de JavaScript
Aunque sforce.one suena como un droide que trabaja en la cantina de Salesforce*, es en realidad un objeto de utilidad que proporciona un número de funciones útiles que puede emplear en su propio código JavaScript.
sforce.one se incorpora automáticamente en su página cuando se ejecuta en Lightning Experience o la aplicación Salesforce. Lo verá en la consola de su depurador de JavaScript y en la lista de recursos de desarrollo web. No hay nada que pueda hacer para agregarlo, y tampoco hay forma de suprimirlo. (Desgraciadamente no hay manera de incorporar sforce.one en sus páginas de Visualforce en Salesforce Classic.)
sforce.one se utiliza principalmente para desencadenar eventos de navegación. Los detalles completos están en una próxima unidad, Gestión de la navegación.
____________________
* No hay cantina de Salesforce. ¡Ay!
Recursos
- Modificar configuración de seguridad de sesión
- Guía del desarrollador de Visualforce
- Red de desarrollo de Mozilla: Elementos de marco flotante HTML (<iframe>)
- Red de desarrollo de Mozilla: Uso de política de seguridad de contenido