Explorar el contenedor de aplicaciones de Visualforce
Objetivos de aprendizaje
- 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
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
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
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
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
- 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
- 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
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
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
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
