Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Pakete und der Anforderungszyklus

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Beschreiben des Unterschieds zwischen einer Visualforce-Seite und einem Aura-Komponentenpaket und ihrer jeweiligen Darstellung in Ressourcen – lokal und in Salesforce
  • Nennen der grundlegenden Unterschiede zwischen dem Anforderungszyklus von Visualforce- und Aura-Komponenten und dem Ort, an dem der Komponentencode ausgeführt wird

Kernkonzepte

Bei diesem Modul sehen wir uns Visualforce-Konzepte und -Funktionen an und beschreiben dann, was ihnen bei Aura-Komponenten am nächsten kommt. Nicht alles lässt sich eindeutig zuordnen. Visualforce und Aura weisen grundlegende Unterschiede bei der Architektur und unterschiedliche Anforderungen für ihre Verwendung zur Anwendungserstellung auf. Wir versuchen, möglichst viele dieser Unterschiede zu erläutern, und verwenden dabei die einzelnen Funktionen als Bezugspunkte.

Bitte beachten Sie, dass wir die hier nicht detailliert auf die Verwendung von Funktionen von Aura-Komponenten eingehen. (Diese Informationen finden Sie im Modul Aura-Komponenten – Grundlagen.) Hier liegt der Schwerpunkt vielmehr darauf, die grundlegenden Unterschiede zu verdeutlichen, damit nicht ähnlich klingende Sachverhalte für Sie zu Rutschen werden, auf denen Sie sich abwärts bewegen.

Konzept: Seite im Vergleich zu Paket

Bevor wir uns einige der abstrakten Konzepte vornehmen, sehen wir uns zunächst etwas Konkretes an, nämlich wie eine einzelne Seite oder Komponente in Salesforce gespeichert wird.

Visualforce-Seiten (und Visualforce-Komponenten, die wir aber vorerst ausklammern) werden in Salesforce als einzelne Entität, einer so genannten "ApexPage" gespeichert. Wenn Sie Salesforce Extensions für Visual Studio Code oder ein anderes Tool verwenden, um Ihre Visualforce-Seiten zur Bearbeitung an den lokalen Speicherort kopieren, wird eine einzelne Visualforce-Seite im Verzeichnis metadata/pages mit zwei Dateien dargestellt:

  • NameIhrerSeite.page
  • NameIhrerSeite.page-meta.xml

Die erste Datei enthält den Code für die Seite, die zweite die Metadaten der Seite (API-Version, mobile Einstellungen usw.).

Ihre Seite kann zwar Abhängigkeiten zu anderen Artefakten (Apex-Steuerfeld, Erweiterung, statische Ressourcen etc.) aufweisen, doch sie sind von der Seite getrennt. Ihre Seite referenziert diese Abhängigkeiten, enthält sie aber nicht.

Eine Aura-Komponente besteht aus mehr als nur einem Codeartefakt plus Metadaten und kann derzeit bis zu acht Codeartefakte plus Metadaten enthalten (neun insgesamt). Aus diesem Grund wird eine einzelne Komponente in einem Paket gespeichert, das Ressourcen enthält. Bei der lokalen Speicherung wird dieses Paket als Ordner mit Dateien dargestellt. Eine komplexe Komponente kann folgendermaßen aussehen: Beispiel für ein Komponentenpaket

Im Verlauf dieses Moduls werden die wichtigsten Ressourcen im Komponentenpaket vorgestellt. Einzelheiten über die restlichen Ressourcen finden Sie unter Komponentenpakete und an anderen Stellen im Entwicklerhandbuch zu Lightning Aura-Komponenten.

Leiter! Führen Sie die folgenden Schritte aus, um ein Aura-Komponentenpaket in Visual Studio Code mit installierten Salesforce Extensions zu erstellen:
  1. Drücken Sie Befehl + Umschalt + P auf einem Mac bzw. Strg + Umschalt + P auf einem Windows- oder Linux-Computer, um die Befehlspalette zu öffnen.
  2. Erstellen Sie in der Befehlspalette mit dem Befehl "SFDX:Create Project" ein Projekt.
  3. Erstellen Sie in der Befehlspalette mit dem Befehl "SFDX:Create Aura Component" ein Komponentenpaket. HinweisIn der praktischen Aufgabe dieser Lektion gestatten Sie Visual Studio Code, Dateien in Ihrer Organisation bereitzustellen. Sie müssen den Benutzernamen und das Kennwort für Ihre Organisation kennen. Wie Sie den Benutzername und das Kennwort für Ihren Trailhead Playground erhalten, erfahren Sie im Modul Trailhead Playground-Management.
    Weitere Informationen finden Sie im Modul Aura-Komponenten – Kenntnisse und Tools.

Konzept: Serverseitig im Vergleich zu clientseitig

Dies ist einer der beiden "offensichtlichsten" Unterschiede. Doch was soll daran eigentlich offensichtlich sein? Wir klären jetzt zunächst, was die beiden Konzepte bedeuten, und befassen uns dann mit einigen ihrer Auswirkungen.

Klassisches Visualforce wird "auf Serverseite" ausgeführt. Das heißt, wenn eine Seite angefordert wird, verarbeitet ein Salesforce-Server das Markup. Der daraus resultierende HTML-Code wird an den Browser des anfordernden Benutzers gesendet, damit die Seite angezeigt werden kann. Beinhaltet die Seite einen Ausdruck (die Dinger zwischen den Trennzeichen "{! }"), wird dieser vom Server ausgewertet. Verweise auf globale Variablen werden auf dem Server aufgelöst. Greift die Seite auf eine Steuerfeldeigenschaft zu, wird dies auf dem Server verarbeitet. Es gibt noch viele weitere Beispiele. Um nochmals unser Thema aufzugreifen: Die gesamte "Framework-Verarbeitung" geschieht auf dem Server. (Hinweis: Wir klammern hier die Verwendung von Visualforce + JavaScript Remoting als bloßen Container für Ihre JavaScript-Anwendung aus. In diesem Fall verwenden Sie Visualforce aber auch nicht im eigentlichen Sinn, sondern nur als Webserver.)

Der Prozess bei Aura-Komponenten ist das genaue Gegenteil. Wenn eine Komponente angefragt wird, werden die Ressourcen der Komponente in ein Paket gepackt und an den Browser des anfordernden Benutzers gesendet. Der Großteil dieser Ressourcen besteht aus JavaScript, mit etwas Markup zur Strukturierung. Der Browser führt das JavaScript aus. Dieses rendert die resultierende HTML und fügt sie in die bestehende "Seite" ein. (Die Begründung für die Anführungszeichen folgt gleich.) Bewertung von Ausdrücken, globale Variablen, Steuerfeldeigenschaften – all dies wird auf dem Client aufgelöst.

Visualforce-Anforderungszyklus Aura Components-Anforderungszyklus
Anforderungszyklus Lightning Components-Anforderungszyklus
  1. Der Benutzer fordert eine Seite an.
  2. Der Server führt den der Seite zugrunde liegenden Code aus und sendet den resultierenden HTML-Code an den Browser.
  3. Der Browser zeigt den HTML-Code an.
  4. Interagiert der Benutzer mit der Seite, wird wieder bei Schritt 1 begonnen.
  1. Der Benutzer fordert eine Anwendung oder Komponente an.
  2. Das Anwendungs- oder Komponentenpaket wird an den Client zurückgegeben.
  3. Der Browser lädt das Paket.
  4. Die JavaScript-Anwendung erzeugt die Benutzeroberfläche.
  5. Bei einer Benutzerinteraktion mit der Seite modifiziert die JavaScript-Anwendung die Benutzeroberfläche wie erforderlich (Rückkehr zum vorherigen Schritt).

Dieser große Unterschied zwischen den Architekturen hat auch große Auswirkungen. Ihre Komponente kann beispielsweise mit einem Benutzer interagieren, ohne dass eine neue Serveranforderung erforderlich ist, doch wenn Ihre Komponente neue Daten speichern oder laden muss, ist dafür eine Serveranforderung notwendig.

Das klingt unkompliziert oder gar offensichtlich. Denken Sie jedoch daran, dass beim klassischen Visualforce für diese Interaktion ein neue, sichtbare Seitenanforderung mit Neuladen notwendig wäre. Bei einer Aura-Komponente fühlt sich die Benutzerinteraktion mit dem clientseitigen JavaScript eher "live” und reaktionsschneller an. Wenn dann aber der Zeitpunkt gekommen ist, dass neue Daten geladen werden müssen, kann die Latenz einer Serveranforderung dem Benutzer plötzlich sehr langsam scheinen, selbst wenn der Gesamtvorgang weniger lange dauert als bei einer Visualforce-Anforderung!

Sie werden feststellen, dass die Performance von Aura-Komponenten insgesamt gut ist. Aber ohne sorgfältiges Entwickeln der Serveranforderungen und ihrer Auswirkungen auf das Nutzungserlebnis haben Ihre Benutzer möglicherweise den Eindruck, die Anwendung sei "langsam".

In den kommenden Themen gehen wir auf weitere Aspekte dieser Diskrepanz ein. Merken Sie sich aber auf jeden Fall die Geschichte mit Clientseite und Serverseite als wichtigen Unterschied im Verhalten der Frameworks.