Exploration du conteneur d'applications Visualforce
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Donner trois différences entre l’exécution de pages Visualforce dans Salesforce Classic et l’exécution de ces mêmes pages dans Lightning Experience.
- Énoncer deux modèles de code communs qui doivent être mis à jour pour fonctionner dans Lightning Experience.
- Décrire deux changements des valeurs par défaut de la page Visualforce lorsqu’elle est exécutée dans Lightning Experience.
Exploration du conteneur d’applications Visualforce
La principale différence entre Visualforce dans Lightning Experience et Visualforce dans Salesforce Classic est l’environnement dans lequel il est exécuté. Dans Salesforce Classic, Visualforce « possède » la page, la requête et l’environnement. Visualforce est le conteneur d’applications. En revanche, dans Lightning Experience, Visualforce est exécuté dans un iframe intégré au conteneur Lightning Experience de taille supérieure.
Cette modification du contexte d’exécution a de nombreuses répercussions sur la façon dont les pages Visualforce peuvent affecter l’ensemble de l’application Salesforce. Nous parlerons de ces modifications dans cette unité, mais garderons les détails de certaines d'entre elles pour les unités qui leur sont consacrées.
Cette unité est un peu plus « en construction » que le reste. La raison est simple : L’impact des problèmes décrits ici dépend fortement de votre code. Nous avons tout fait pour garantir un fonctionnement sans heurt et vous avez peu de chances de rencontrer les problèmes présentés ici. Néanmoins, nous ne pouvons pas prévoir toutes les situations et les utilisations de Visualforce. Nous présentons ici les principaux effets de Lightning Experience sur Visualforce. Lorsque nous aurons davantage d’informations sur l’impact réel, nous pourrons vous donner plus de détails sur la résolution des problèmes éventuels.
Le conteneur externe de Lightning Experience
Commençons avec le conteneur externe, l'application Lightning Experience. Le conteneur Lightning Experience est une application Web monopage (SPA) accessible grâce à l'URL /lightning. La page /lightning se charge, son code démarre et ce code de l'application prend le contrôle de l'environnement.
Le processus qui permet à une application Web monopage de charger ses ressources (en général un shell HTML et beaucoup de JavaScript) est à la fois complexe et intéressant. Si vous avez travaillé avec des infrastructures JavaScript comme AngularJS ou React, vous connaissez plutôt bien les bases du démarrage de Lightning Experience, sous la forme de /lightning. Pour être honnête, la totalité des détails n'a pas d'importance. Vous n'avez aucun contrôle sur cela, et l'implémentation ne cesse d'évoluer.
Voici les principaux éléments à connaître : Lightning Experience, ou /lightning, se charge de la requête. Ce n’est pas le cas de votre page Visualforce. Votre page doit respecter les contraintes imposées par Lightning Experience. Lightning Experience correspond au contexte parent alors que votre page Visualforce correspond au contexte enfant. Les enfants doivent obéir à leurs parents.
Certaines de ces contraintes, comme la taille du cadre dans lequel votre page Visualforce est affichée, sont directement imposées par Lightning Experience. Il est plus facile de les comprendre et de travailler avec, nous en parlerons dans un instant.
D'autres contraintes sont implicites et dictées non pas par Lightning Experience, mais par le navigateur qui l'exécute. Il s'agit principalement de contraintes liées à la sécurité et à l'exécution de JavaScript. La plupart des pages ne sont pas impactées par ces contraintes de sécurité, et celles qui le sont rencontrent généralement des problèmes, avec des messages d'erreur clairs. Les erreurs JavaScript sont plus difficiles à découvrir et à diagnostiquer, mais il existe quelques règles générales que nous évoquerons bientôt.
L’iframe Visualforce
Lorsque votre page Visualforce est exécutée dans Lightning Experience, elle est affichée dans un iframe HTML. Un iframe crée un contexte de navigation intégré qui constitue effectivement une « fenêtre » du navigateur séparée du contexte principal de navigation Lightning Experience. L’iframe crée une frontière entre la page Visualforce et son parent, l’application Lightning Experience.
L’avantage d’exécuter des pages Visualforce dans un iframe réside dans le fait que, pour les pages qui ne doivent pas accéder ou modifier le contexte supérieur de navigation, l’affichage dans l’iframe ressemble à s’y méprendre à celui dans Salesforce Classic. C’est pourquoi il n’est pas nécessaire de modifier toutes vos pages Visualforce pour qu’elles s’adaptent à l’environnement de requête de Lightning Experience, qui est, au-delà de son apparence, très différent. C’est une composante importante de la stratégie relative au bon fonctionnement pour la prise en charge de Visualforce.
Bien sûr, le revers de la médaille est que les pages qui doivent accéder au contexte supérieur de navigation auront besoin de quelques réglages. Nous évoquerons quelques cas spécifiques dans la section suivante.
Si votre page communique avec des services au-delà de Salesforce, la frontière que constitue l'iframe peut mener à mettre à jour les paramètres CORS, du site distant, des détournements de clics ou du mécanisme de la stratégie de sécurité de contenu de votre organisation. Ces changements spécifiques dépendant de stratégies et de paramètres de sécurité extérieurs à Salesforce, il nous est impossible de vous fournir une procédure à ce sujet. Il s'agit juste ici de vous prévenir.
Impact du nouveau conteneur
Les effets du nouveau conteneur Visualforce (intégration de la page Visualforce à un iframe dans l’application Lightning Experience) peuvent être grossièrement divisés en deux catégories que nous appellerons sécurité et étendue.
Nous insistons de nouveau sur un point : beaucoup, voire la plupart des pages Visualforce ne seront pas concernées par ces questions. Pour celles qui le sont, nous partons du principe « qu'un homme averti en vaut deux ». Vous identifierez plus rapidement la source du problème si nous en avons déjà discuté.
Impact en termes de sécurité
Les éléments de sécurité pouvant être affectés sont notamment les suivants :
- Maintenance et renouvellement de session
- L’authentification
- Requêtes inter-domaines
- Restrictions d'intégration
Nous avons rapidement évoqué quelques-uns de ces éléments, ceux qui concernent les requêtes inter-domaines. Ainsi, si le contenu d'une fenêtre complète de navigateur provient de requêtes de différents serveurs et services, il est possible qu'une de ces requêtes éprouve des difficultés à s'afficher dans un contexte pour lequel elle n'est pas préparée. Votre mission, si le besoin s'en fait sentir, est de préparer ces services à gérer des requêtes ayant pour but d'être assemblées dans le contexte Lightning Experience. Comme nous l'avons dit précédemment, les détails varient, il nous est donc impossible de donner des réponses spécifiques.
La maintenance de session est un élément sur lequel nous souhaitons nous arrêter. Dans le cadre de ce qui nous intéresse ici, une « session » est en fait une sorte de jeton que votre navigateur utilise d'une requête à l'autre, afin que vous n'ayez pas à saisir votre identifiant et votre mot de passe pour chaque requête. Vous devez souvent accéder à la session en cours en utilisant la variable globale $Api.Session_ID.
Voici ce dont vous devez vous souvenir. $Api.Session_ID renvoie des valeurs différentes selon le domaine de la requête. C’est parce que l’ID de la session varie au cours de cette dernière, à chaque fois que vous franchissez la frontière d’un nom d’hôte, par exemple de .salesforce.com à .force.com. Normalement, Salesforce gère de manière transparente la transmission de sessions entre les domaines. Toutefois, si vous transmettez l'ID de la session autour de vous, rappelez-vous que vous devrez peut-être accéder de nouveau à $Api.Session_ID depuis le bon domaine pour garantir la validité de l'ID de la session.
Les pages Lightning Experience et Visualforce ne sont pas uniquement affichées dans des contextes de navigateur différents, elles proviennent également de domaines distincts. Par conséquent, même si tout est affiché dans une seule fenêtre du navigateur, l’ID de session dans l’iframe Visualforce sera différent de l’ID de session hors de l’iframe, dans une autre partie de Lightning Experience. Salesforce et Lightning Experience gèrent ceci de manière transparente dans le cas d’une utilisation normale. Toutefois, si vous transmettez l'ID de la session autour de vous, comme une entrée lors d'une fête (ce qui n'est généralement pas une bonne idée), vous devrez peut-être vérifier la façon dont vous le gérez.
Impact en termes d'étendue
En évoquant l'étendue, nous parlons essentiellement des éléments suivants :
- Accès et modification du DOM
- Accès, visibilité et étendue de JavaScript
- Variables globales de JavaScript comme window.location
Si cette liste vous paraît compliquée ou obscure, ne vous inquiétez pas, nous pouvons la résumer en quelque chose de simple et de facile à mémoriser. Ne touchez pas aux affaires des autres. De manière spécifique, votre code JavaScript (ainsi que les règles de feuilles de style, dans ce cas) peut affecter les éléments (nœuds DOM, variables JavaScript, etc.) du contexte de navigation de votre page, mais il ne peut pas accéder aux éléments d'un autre contexte de navigation, comme le contexte parent Lightning Experience. Ne touchez pas aux contextes des autres !
Concrètement, le modèle de code le plus commun pour accomplir ce genre de choses est de manipuler window.location pour naviguer vers une autre page. Il s'agit de quelque chose de très répandu, nous avons rédigé des informations sur ce sujet en particulier. Bon, d'ici à ce que vous en ayez fini avec ce module, promis, vous ne supporterez plus d'en entendre parler.
Une dernière chose. Si vous êtes un développeur en JavaScript expérimenté, vous pensez sans doute déjà à la manière de traiter les problèmes du type « Je n’ai pas accès au contexte de navigation parent », en utilisant contentWindow, window.parent, ou des outils similaires. Oubliez cela. Vous seriez sans doute confronté à la same-origin policy (SOP) (souvenez-vous, Visualforce et Lightning Experience proviennent de différents domaines). Et même si ce n'est pas le cas, vous remplacez sans doute de gros bogues « bloquants » par de petits bogues intermittents. À quoi souhaitez-vous consacrer votre temps ? À jouer au débogueur ou à bien faire les choses ?
Bien faire les choses signifie appeler des API disponibles sur vos pages Visualforce, principalement pour la navigation. Si vous avez vraiment besoin de modifier des éléments au-delà des limites de la fenêtre, utilisez window.postMessage pour envoyer un message afin de recevoir du code dans l’autre cadre.
Visualforce : réglages par défaut et changements de l’environnement dans Lightning Experience
Lorsque vos pages Visualforce sont exécutées dans Lightning Experience, de nombreux changements mineurs se produisent en arrière-plan. Ceux-ci permettent à de nombreuses pages de fonctionner normalement dans le conteneur Lightning Experience, et vous serez parfois ravis qu'ils soient présents. Vous voudrez tout de même savoir qu'ils se produisent, notamment si vous travaillez sur des flux d'application avancés ou si vous êtes en train de résoudre un problème complexe.
Certains de ces changements sont simples, et même évidents une fois que vous y réfléchissez. Par exemple, les pages Visualforce exécutées dans Lightning Experience n’affichent jamais l’en-tête et la barre latérale standard de Salesforce Classic. D'autres changements sont moins visibles, mais leur impact est tout aussi important.
Les attributs <apex:page> showHeader et sidebar sont toujours définis sur « false »
Ces attributs affectent l’en-tête et la barre latérale de Salesforce Classic sur les pages Visualforce. L'en-tête et la barre latérale de Salesforce Classic sont toujours supprimés si les pages sont exécutées dans Lightning Experience, afin de privilégier les éléments de navigation de Lightning Experience. Aucun attribut correspondant n'affecte l'en-tête et la barre latérale de Lightning Experience, car ils ne peuvent pas être supprimés.
Si votre page est partagée entre Salesforce Classic et Lightning Experience, vous pouvez tout de même définir ces attributs sur les valeurs que vous souhaitez utiliser lorsque la page est exécutée dans Salesforce Classic.
L’attribut standardStylesheets de <apex:page>, qui permet de déterminer s’il faut inclure ou supprimer les feuilles de style standard de Salesforce Classic, reste identique dans Lightning Experience. Il est défini par défaut sur « true » dans Lightning Experience, mais vous pouvez le modifier.
L’objet utilitaire JavaScript sforce.one
sforce.one vous fait penser à un droïde qui travaille dans la cantina de Salesforce*, n’est-ce pas ? Pourtant, cet objet utilitaire offre plusieurs fonctions utiles pour votre propre code JavaScript.
sforce.one est automatiquement injecté dans votre page lorsque celle-ci est exécutée dans Lightning Experience ou dans l’application Salesforce. Vous le verrez dans votre console de débogage JavaScript et dans la liste des ressources du développeur Web. Vous n'avez rien à faire pour l'ajouter. Par ailleurs, il n'y a aucun moyen de le supprimer. (Malheureusement, il est impossible d’injecter sforce.one sur vos pages Visualforce dans Salesforce Classic.)
sforce.one est principalement utilisé pour déclencher des événements de navigation. Les détails complets sont disponibles dans une prochaine unité, Gestion de la navigation.
____________________
* Il n’existe aucune cantina Salesforce. Hélas !
Ressources
- Modify Session Security Settings
- Visualforce Developer’s Guide
- Mozilla Development Network : Élément HTML Inline Frame (<iframe>)
- Mozilla Development Network : Using Content Security Policy