Erkunden des Visualforce-Anwendungscontainers
Lernziele
Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
- Beschreiben der drei Unterschiede zwischen Visualforce-Seiten, die in Salesforce Classic verwendet werden, und denselben Seiten in Lightning Experience
- Beschreiben von zwei gebräuchlichen Codemustern, die aktualisiert werden müssen, damit sie in Lightning Experience funktionieren
- Auflisten von zwei Änderungen der Standardwerte für Visualforce-Seiten bei Verwendung in Lightning Experience
Erkunden des Visualforce-Anwendungscontainers
Der Hauptunterschied zwischen Visualforce in Lightning Experience und Visualforce in Salesforce Classic ist die Umgebung, in der Visualforce ausgeführt wird. In Salesforce Classic ist Visualforce "Besitzer" der Seite, Anforderung oder Umgebung. Visualforce ist der Anwendungscontainer. In Lightning Experience wird Visualforce jedoch in einem IFrame ausgeführt, der im größeren Lightning Experience-Container eingeschlossen ist.
Diese Änderung des Ausführungskontexts hat eine Reihe von Auswirkungen auf den möglichen Einfluss von Visualforce-Seiten auf die ganze Salesforce-Anwendung. Diese Änderungen werden in dieser Lektion behandelt. Umfassende Einzelheiten einiger Änderungen werden jedoch in eigenen Lektionen beschrieben.
Diese Lektion ist im Vergleich zum Rest "im Aufbau befindlich". Der Grund ist einfach: Die Auswirkung der hier beschriebenen Aspekte hängt wesentlich von Ihrem Code ab. Es wurden umfangreiche Anstrengungen unternommen, damit die Funktionalität erhalten bleibt. In den meisten Fällen haben die beschriebenen Aspekte für Sie kaum oder keine Auswirkungen. Es ist aber nicht möglich, alle Verwendungsmöglichkeiten von Visualforce vorherzusehen. Hier werden die allgemeinen Aspekte skizziert, wie Lightning Experience Visualforce beeinflusst. Im Verlauf unserer gemeinsamen Gespräche und sobald mehr über die eigentlichen Auswirkungen bei den Kunden bekannt ist, bieten wir Ihnen Erläuterungen mit Einzelheiten zur Lösung bestimmter Probleme an.
Der äußere Lightning Experience-Container
Lassen Sie und mit dem äußeren Container beginnen, der Lightning Experience-Anwendung. Der Lightning Experience-Container ist eine "Einzelseitenanwendung" (SPA), auf die über den URL /lightning zugegriffen wird. Die /lightning-Seite wird geladen, der zugehörige Code wird aufgerufen und der betreffende Anwendungscode übernimmt die Umgebung.
Der Prozess, mit dem eine Einzelseitenanwendung zu zugehörigen Ressourcen lädt, normalerweise eine statische HTML-Shell und eine Menge JavaScript, ist sowohl interessant als auch komplex. Wenn Sie mit JavaScript-Frameworks wie AngularJS oder React gearbeitet haben, sind Ihnen die Grundlagen der Startweise von Lightning Experience in der Form von /lightning weitgehend bekannt. Die vollständigen Einzelheiten sind ehrlich gesagt uninteressant. Sie haben keinerlei Einflussmöglichkeit darauf und die Implementierung wird laufend weiterentwickelt.
Hier finden Sie alles, was Sie wissen müssen: Lightning Experience oder /lightning ist für die Anforderung zuständig, nicht die Visualforce-Seite. Ihre Seite muss mit den Einschränkungen klar kommen, die Lightning Experience auferlegt Lightning Experience ist der übergeordnete Kontext, Ihre Visualforce-Seite der untergeordnete Kontext. Die Untergeordneten folgen den Übergeordneten.
Einige dieser Einschränkungen, z. B. die Größe des Frames, in dem die Visualforce-Seite angezeigt wird, werden direkt von Lightning Experience vorgegeben. Sie sind leichter zu verstehen und zu verwenden. Außerdem werden wir uns gleich näher damit beschäftigen.
Andere Einschränkungen sind implizit und werden nicht von Lightning Experience, sondern vom verwendeten Browser vorgeschrieben. Dabei handelt es sich meistens um Sicherheits- und JavaScript-Ausführungseinschränkungen. Diese Sicherheitseinschränkungen haben keine Auswirkung auf die meisten Seiten. Die betroffenen Seiten schlagen normalerweise frühzeitig mit klaren Fehlermeldungen fehl. JavaScript-Fehler sind schwieriger zu erkennen und zu diagnostizieren. Es gibt jedoch einige allgemein gültige Regeln, die weiter unten behandelt werden.
Der Visualforce-IFrame
Wenn Ihre Visualforce-Seite in Lightning Experience ausgeführt wird, wird sie in einem HTML-IFrame angezeigt. Ein IFrame erstellt einen eingebetteten Browserkontext, der im Grunde ein vom Lightning Experience-Hauptbrowserkontext unabhängiges "Browserfenster" ist. Der IFrame erstellt eine Grenze zwischen der Visualforce-Seite und der übergeordneten Lightning Experience-Anwendung.
Der Vorteil der Ausführung von Visualforce -Seiten in einem IFrame besteht darin, dass Seiten, die nicht auf den Browserkontext auf der obersten Ebene zugreifen oder diesen ändern müssen und im IFrame ausgeführt werden, fast genauso aussehen wie eine in Salesforce Classic ausgeführte Seite. Dies ist der Grund dafür, dass Sie keine Visualforce-Seiten ändern und an die sehr unterschiedliche, im Hintergrund wirkende Anforderungsumgebung von Lightning Experience anpassen müssen. Hierbei handelt es sich um einen wesentlichen Teil der "Funktioniert"-Strategie zur Unterstützung von Visualforce.
Die Kehrseite ist natürlich, dass bei Seiten, die auf den Browserkontext auf der obersten Ebene zugreifen müssen, Anpassungen vorgenommen werden müssen. Einige Besonderheiten werden im nächsten Abschnitt behandelt.
Wenn die Seite mit anderen Diensten außer Salesforce kommuniziert, kann die IFrame-Grenze auch dazu führen, dass Sie die CORS-Einstellungen, Remote-Standorteinstellungen, Clickjack-Einstellungen oder Inhaltssicherheitsrichtlinie Ihrer Organisation ändern müssen. Die diese von Sicherheitsrichtlinien und -einstellungen außerhalb von Salesforce abhängigen, ist es nicht möglich, ein Rezept für bestimmte Änderungen zu geben. Sie sollten hier lediglich darauf hingewiesen werden.
Auswirkung des neuen Containers
Die Auswirkungen des neuen Visualforce-Containers, der die Visualforce-Seite in einen IFrame in der Lightning Experience-Anwendung einbettet, kann weitgehend in zwei Kategorien unterteilt werden: Sicherheit und Geltungsbereich.
Erneut muss darauf hingewiesen werden, dass diese Aspekte auf viele oder sogar die meisten Visualforce-Seiten keinen Einfluss haben. Dies kann aber nicht ausgeschlossen werden, sodass unserer Meinung nach "Gefahr erkannt, Gefahr gebannt" besser ist. Sie finden die Ursache des Problems schneller, wenn dies gemeinsam besprochen wurde.
Auswirkung auf die Sicherheit
Zu den Sicherheitselementen, die beeinflusst werden können, zählen:
- Verwaltung und Erneuerung von Sitzungen
- Authentifizierung
- Domänenübergreifende Anforderungen
- Einbetten von Einschränkungen
Einige dieser Elemente wurden bereits kurz behandelt, z. B. die Probleme bei domänenübergreifenden Anforderungen. Wenn der Inhalt im vollständigen Browserfenster aus Anforderungen an verschiedene Server und Dienste stammt, besteht für jede Anforderung die Möglichkeit, dass die Anzeige in einem Kontext verhindert wird, in dem dies nicht vorgesehen ist. Sie müssen dann die betreffenden Dienste aufbereiten, dass Anforderungen verarbeitet werden können, die im Lightning Experience-Kontext zusammengesetzt werden. Wie bereits erwähnt, sind die Details unterschiedlich, sodass hier keine allgemein gültigen Antworten möglich sind.
Ein Aspekt, auf den besonders hingewiesen werden soll, ist die Sitzungsverwaltung. Eine "Sitzung" in diesem Zusammenhang ist im Grunde eine Art Token, das der Browser von Anforderung zu Anforderung wiederverwendet, damit Sie nicht bei jeder Anforderung Benutzername und Kennwort eingeben müssen. Oftmals müssen Sie mit der globalen Variablen $Api.Session_ID auf die aktuelle Sitzung zugreifen.
Dabei muss Folgendes beachtet werden. $Api.Session_ID gibt abhängig von der Domäne der Anforderung unterschiedliche Werte zurück. Dies liegt daran, dass die Sitzungs-ID in einer Sitzung immer geändert wird, wenn eine Hostnamengrenze überschritten wird, z. B. von .salesforce.com zu .force.com. Normalerweise handhabt Salesforce die Übergabe von Sitzungen zwischen Domänen transparent. Wenn Sie die Sitzungs-ID aber selbst verwalten, müssen Sie darauf achten, dass Sie von der richtigen Domäne aus auf $Api.Session_ID zugreifen, um eine gültige -Sitzungs-ID sicherzustellen.
Lightning Experience- und Visualforce-Seiten werden nicht nur in verschiedenen Browserkontexten verwaltet, sondern auch von verschiedenen Domänen unterstützt. Obwohl alles in einem Browserfenster angezeigt wird, stimmt die Sitzungs-ID innerhalb des Visualforce-IFrames von der Sitzungs-ID außerhalb des IFrames (in einem anderen Teil von Lightning Experience) ab. Salesforce und Lightning Experience handhaben dies normalerweise transparent. Wenn Sie die Sitzungs-ID jedoch wie die Vorspeise bei einer Party herumreichen (normalerweise keine gute Idee), müssen Sie die jeweilige Verarbeitung u. U. überprüfen.
Auswirkung auf den Geltungsbereich
Unter Geltungsbereich werden hauptsächlich folgende Dinge verstanden:
- DOM-Zugriff und -Modifikation
- JavaScript-Bereich, -Sichtbarkeit und -Zugriff
- Globale JavaScript-Variablen wie window.location
Machen Sie sich keine Sorgen, falls diese Liste kompliziert oder verwirrend klingt: Sie müssen sich lediglich folgenden einfachen Grundsatz merken: Lassen Sie Code anderer Benutzer in Ruhe. Insbesondere kann Ihr JavaScript-Code (und zugehörige Stylesheetregeln) Elemente, z. B. DOM-Knoten, JavaScript-Variables usw. im Browserkontext Ihrer Seite beeinflussen, aber nicht auf Elemente in einem anderen Browserkontext, z. B. den übergeordneten Lightning Experience-Kontext, zugreifen. Lassen Sie Code anderer Kontexte in Ruhe!
Praktisch gesehen betreffen derartige Änderungen meistens window.location, um zu einer anderen Seite zu navigieren. Da dies sehr häufig passiert, werden wir uns diesem Problem ausführlich widmen. Am Ende dieses Moduls werden Sie überdrüssig sein, von diesem Problem zu hören.
Ein letzter Hinweis. Als erfahrener JavaScript-Entwickler, denken Sie vielleicht, dass Sie wissen, wie Sie mit Problemen beim Zugriff auf den übergeordneten Browserkontext umgehen müssen, indem Sie contentWindow, window.parent o. ä. verwenden. Tun Sie das bitte nicht, da Sie sich wahrscheinlich in der Same-Origin-Richtlinie verheddern. (Denken Sie daran, dass Visualforce und Lightning Experience unterschiedliche Domänen verwenden!) Aber selbst wenn dies nicht der Fall ist, ersetzen Sie u. U. offensichtliche, blockierende Fehler durch subtile, zeitweise auftretende Fehler. Womit möchten Sie Ihre Zeit lieber verbringen: Korrekten Code schreiben oder Fehler suchen?
Korrekten Code schreiben heißt, die in Ihren Visualforce-Seiten (hauptsächlich für die Navigation) zur Verfügung gestellten APIs aufzurufen. Wenn Sie wirklich frameüberschreitende Dinge beeinflussen müssen, verwenden Sie window.postMessage, um eine Nachricht an den Empfängercode im anderen Frame zu senden.
Visualforce-Standardwerte und Umgebungsänderungen in Lightning Experience
Wenn Ihre Visualforce-Seiten in Lightning Experience ausgeführt werden, werden im Hintergrund einige Änderungen auf untergeordneter Ebene durchgeführt. Diese Änderungen sorgen dafür, dass die meisten Seiten im Lightning Experience-Container "funktionieren". Bisweilen können Sie sogar froh sein, dass sie überhaupt vorhanden sind. Sie möchten aber weiterhin sicher sein, dass sie funktionieren, insbesondere bei Verwendung von weiterentwickelten Anwendungsabläufen oder bei der Fehlerbehebung eines kniffligen Problems.
Einige dieser Änderungen sind einfach und bei genauer Betrachtung offensichtlich. In Visualforce-Seiten, die in Lightning Experience ausgeführt werden, sind beispielsweise die Standardkopfzeile und -randleiste von Salesforce Classic immer unterdrückt. Andere Änderungen sind nicht so erkennbar, haben aber dennoch große Auswirkungen.
<apex:page>-Attribute showHeader und Sidebar sind immer FALSE
Diese Attribute wirken sich auf die Kopfzeile und Randleiste von Salesforce Classic auf Visualforce-Seiten aus. Die Kopfzeile und Randleiste von Salesforce Classic werden zugunsten von Lightning Experience-Navigationselementen immer unterdrückt, wenn Seiten in Lightning Experience angezeigt werden. Es gibt keine entsprechenden Attribute, um Kopfzeile und Randleiste von Lightning Experience zu beeinflussen, da sie nicht unterdrückt werden können.
Wenn die Seite gemeinsam in Salesforce Classic und Lightning Experience genutzt wird, können Sie diese Attribute dennoch auf die gewünschten Werte festlegen, wenn die Seite in Salesforce Classic ausgeführt wird.
Das standardStylesheets-Attribut von <apex:page>, das bestimmt, ob normale Salesforce Classic-Stylesheets berücksichtigt oder unterdrückt werden, wird von Lightning Experience nicht beeinflusst. Der Standardwert in Lightning Experience ist also TRUE. Sie können den Wert aber ändern.
Das JavaScript-Dienstprogrammobjekt sforce.one
sforce.one klingt zwar erst einmal wie ein Roboter, der in der Salesforce-Kantine* arbeitet, tatsächlich handelt es sich aber um ein Dienstprogrammobjekt, das eine Vielzahl von nützlichen Funktionen bereitstellt, die Sie in Ihrem JavaScript-Code verwenden können.
sforce.one wird automatisch in Ihre Seite injiziert, wenn sie in Lightning Experience oder der Salesforce-Anwendung ausgeführt wird. Es wird in der Konsole des JavaScript-Debuggers und in der Ressourcenliste für Webentwickler angezeigt. Sie brauchen nichts zu tun, um es hinzuzufügen. Genauso gibt es keine Möglichkeit, es zu unterdrücken. (Leider gibt es keine Möglichkeit, sforce.one in Visualforce-Seiten in Salesforce Classic einzubinden.)
sforce.one wird hauptsächlich verwendet, um Navigationsereignisse auszulösen. Die vollständigen Einzelheiten erfahren Sie in der noch bevorstehenden Einheit Verwalten der Navigation.
____________________
* Es gibt gar keine Salesforce-Kantine. Leider.
Ressourcen
- Modify Session Security Settings
- Visualforce Developer’s Guide
- Mozilla Development Network: HTML Inline Frame Element (<iframe>)
- Mozilla Development Network: Using Content Security Policy