Exploration du conteneur d'applications Visualforce
Objectifs de formation
- 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
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
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
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
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é
- 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
- 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
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 »
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 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
