Single Page Applications (SPAs) können ansprechende Erlebnisse für Website-Benutzer bieten. Entwickler möchten Sites mit SPA Frameworks erstellen können und Autoren möchten Inhalte in Adobe Experience Manager (AEM) nahtlos für eine Site bearbeiten, die mit solchen Frameworks erstellt wurde.
Dieser Artikel enthält wichtige Fragen, die zu beachten sind, wenn ein Frontend-Entwickler damit beauftragt wird, eine SPA für AEM zu entwickeln, und gibt einen Überblick über die Architektur der AEM bei der Bereitstellung von SPA auf AEM.
Der SPA Editor ist die empfohlene Lösung für Projekte, die SPA Framework-basiertes Client-seitiges Rendering erfordern (z. B. React oder Angular).
Bei der Entwicklung von Single Page Applications in AEM wird davon ausgegangen, dass sich die Frontend-Entwicklungspersonen beim Erstellen einer SPA an die üblichen Best Practices halten. Wenn Sie als Frontend-Entwickler diese allgemeinen Best Practices und einige AEM-spezifische Prinzipien befolgen, wird Ihr SPA mit AEM und die Inhaltsbearbeitungsfunktionen.
Wenn Sie sich bei der Entwicklung Ihrer SPA an diese Grundsätze halten, wird diese so flexibel und zukunftssicher wie möglich sein sowie die Nutzung aller unterstützten AEM Authoring-Funktionen ermöglichen.
Wenn Sie keine Unterstützung für AEM Authoring-Funktionen benötigen, sollten Sie möglicherweise ein anderes SPA-Design-Modell in Betracht ziehen.
Wie bei der Entwicklung von Komponenten sollten Ihre Komponenten so gestaltet sein, dass sie maximale Portabilität aufweisen. Alle Muster, die der Portabilität oder Wiederverwendbarkeit der Komponenten zuwiderlaufen, sollten vermieden werden, um Kompatibilität, Flexibilität und Wartbarkeit in Zukunft zu garantieren.
Die resultierende SPA sollte mit hochgradig portablen und wiederverwendbaren Komponenten erstellt werden.
Die Frontend-Entwicklungsperson muss sich als verantwortlich für die Einrichtung einer Bibliothek mit SPA-Komponenten betrachten, die zum Erstellen der App verwendet werden. Die Frontend-Entwicklungsperson hat die vollständige Kontrolle über die interne Struktur der Komponenten. AEM besitzt jedoch jederzeit die Struktur der Site.
Das bedeutet, dass der Frontend-Entwickler Kundeninhalte vor oder nach dem Einstiegspunkt der Komponenten hinzufügen und innerhalb der Komponente auch Drittanbieter-Aufrufe durchführen kann. Der Frontend-Entwickler hat jedoch beispielsweise nicht die volle Kontrolle darüber, wie die Komponenten verschachtelt sind.
Die SPA sollte sich nur auf dynamisches Rendering von Inhalten stützen. Dies ist die Standarderwartung, bei der AEM alle untergeordneten Elemente der Inhaltsstruktur abruft und rendert.
Jedes explizite Rendering, das auf bestimmte Inhalte verweist, gilt als statisches Rendering und wird zwar unterstützt, ist jedoch nicht mit den Inhaltserstellungsfunktionen von AEM kompatibel. Es widerspricht auch dem Grundsatz der Portabilität.
Wie beim Rendering auch sollte das gesamte Routing dynamisch sein. In AEM sollte die SPA stets für das Routing verantwortlich sein; AEM lauscht darauf und ruft Inhalte auf dieser Basis ab.
Jedes statische Routing verstößt gegen den Grundsatz der Portabilität und schränkt den Autor ein, da es nicht mit den Inhaltserstellungsfunktionen von AEM kompatibel ist. Bei statischem Routing müsste der Autor beispielsweise den Frontend-Entwickler bitten, dies zu tun, wenn der Inhaltsautor eine Route ändern oder eine Seite ändern möchte.
Für jedes AEM-Projekt sollte der AEM-Projektarchetyp genutzt werden, der SPA-Projekte mithilfe von React oder Angular unterstützt und das SPA-SDK verwendet.
Wenn die Prinzipien der Entwicklung von SPAs in AEM befolgt werden, wird Ihre SPA mit allen unterstützten Inhaltserstellungsfunktionen von AEM zusammenarbeiten.
Es kann jedoch Fälle geben, in denen dies nicht wirklich erforderlich ist. Die folgende Tabelle bietet einen Überblick über die verschiedenen Design-Modelle sowie ihre Vor- und Nachteile.
Design-Modell |
Vorteile | Nachteile |
---|---|---|
AEM wird als Headless-CMS ohne das SPA Editor SDK-Framework verwendet. | Die Frontend-Entwicklungsperson hat die vollständige Kontrolle über die App. | Inhaltsautorinnen bzw. -autoren können das Inhaltserstellungserlebnis von AEM nicht nutzen. Der Code ist weder portabel noch wiederverwendbar, wenn er statische Referenzen oder Routing enthält. Eine Verwendung des Vorlageneditors ist nicht zulässig. Daher muss die Frontend-Entwicklungsperson bearbeitbare Vorlagen über das JCR verwalten. |
Die Frontend-Entwicklungsperson verwendet das SPA-Editor-SDK-Framework, gibt jedoch für die Inhaltsautorinnen und -autoren nur ausgewählte Bereiche frei. | Der Entwickler behält die Kontrolle über die App, indem er Authoring nur in eingeschränkten Bereichen der App aktiviert. | Autoren von Inhalten sind auf eine begrenzte Anzahl von AEM-Inhaltserstellungsfunktionen beschränkt. Der Code ist möglicherweise weder portabel noch wiederverwendbar, wenn er statische Referenzen oder statisches Routing enthält. Die Verwendung des Vorlageneditors ist nicht zulässig, daher muss der Frontend-Entwickler bearbeitbare Vorlagen über das JCR verwalten. |
Das Projekt nutzt komplett das SPA-Editor-SDK, die Frontend-Komponenten werden als Bibliothek entwickelt und die Verwaltung der Inhaltsstruktur der App wird an AEM übertragen. | Die App ist wiederverwendbar und portabel. Der Inhaltsautor kann die App mit den Inhaltserstellungsfunktionen von AEM bearbeiten. Die SPA ist mit dem Vorlageneditor kompatibel. |
Der Entwickler hat keine Kontrolle über die Struktur der App und den Teil des Inhalts, der an AEM delegiert wurde. Der Entwickler kann aber Bereiche der App für Inhalte reservieren, die nicht mit AEM erstellt werden sollen. |
Obwohl alle Modelle in AEM unterstützt werden, erfolgt dies nur durch Implementierung des dritten Modells (und folgt daher der empfohlenen SPA Entwicklungsgrundsätze in AEM) können Inhaltsautoren mit dem Inhalt der SPA in AEM interagieren und ihn bearbeiten, wie sie es gewohnt sind.
Wenn Ihre SPA die SPA-Entwicklungsprinzipien für AEM einhält, funktioniert Ihre SPA in AEM und ist mit dem AEM-SPA-Editor bearbeitbar.
Führen Sie die folgenden Schritte aus, um Ihre bestehende SPA für die Zusammenarbeit mit AEM bereit zu machen.
Gestalten Sie Ihre JS-Komponenten modular.
Gestalten Sie sie so, dass sie in beliebiger Reihenfolge, Position und Größe gerendert werden können.
Verwenden Sie die vom Adobe SDK bereitgestellten Container, um Ihre Komponenten auf dem Bildschirm zu platzieren.
AEM bietet eine Seiten- und Absatzsystemkomponente, die Sie verwenden können.
Erstellen Sie für jede JS-Komponente eine AEM-Komponente.
Die AEM-Komponenten definieren den Dialog und die JSON-Ausgabe.
Wenn eine Frontend-Entwicklungsperson damit beauftragt wird, eine SPA für AEM zu erstellen, besteht die wichtigste Aufgabe darin, sich mit ihr auf die Komponenten und ihre JSON-Modelle zu einigen.
Im Folgenden werden die Schritte beschrieben, die ein Frontend-Entwickler bei der Entwicklung eines SPA für AEM durchführen muss.
Einigen Sie sich hinsichtlich der Komponenten und ihrer JSON-Modelle
Frontend-Entwickler und Back-End-AEM-Entwickler müssen sich darauf einigen, welche Komponenten erforderlich sind, und ein Modell erstellen, damit eine Eins-zu-Eins-Übereinstimmung zwischen SPA Komponenten und den Backend-Komponenten besteht.
AEM-Komponenten sind weiterhin erforderlich, insbesondere um Bearbeitungsdialogfelder bereitzustellen und das Komponentenmodell zu exportieren.
In React-Komponenten greifen Sie auf das Modell zu überthis.props.cqModel
Sobald Komponenten vereinbart sind und das JSON-Modell vorhanden ist, kann der Frontend-Entwickler die SPA entwickeln und über this.props.cqModel
bequem auf das JSON-Modell zugreifen.
Implementieren der render()
-Methode der Komponente
Der Frontend-Entwickler implementiert die render()
-Methode nach Belieben und kann die Felder der cqModel
-Eigenschaft verwenden. Dadurch werden das DOM und die HTML-Fragmente ausgegeben, die in die Seite eingefügt werden. Dabei handelt es sich um die Standardmethode zur Erstellung einer App in React.
Ordnen Sie die Komponente dem AEM-Ressourcentyp zu viaMapTo()
Die Zuordnung speichert Komponentenklassen und wird von der bereitgestellten Container
-Komponente intern zum Abrufen und dynamischen Instanziieren von Komponenten basierend auf dem angegebenen Ressourcentyp genutzt.
Sie dient als „Kleber“ zwischen Front- und Backend, sodass der Editor weiß, welchen Komponenten die React-Komponenten entsprechen.
Page
und ResponsiveGrid
sind gute Beispiele für Klassen, die den grundlegenden Container
erweitern.
Definieren Sie EditConfig
der Komponente als Parameter fürMapTo()
Dieser Parameter teilt dem Editor mit, wie die Komponente benannt werden soll, solange sie noch nicht gerendert ist oder über keinen zu rendernden Inhalt verfügt.
Erweitern Sie die bereitgestellte Container
-Klasse für Seiten und Container
Seiten und Absatzsysteme sollten diese Klasse erweitern, damit die Übertragung an innere Komponenten erwartungsgemäß funktioniert.
Implementieren Sie eine Routing-Lösung, die die HTML5-History
-API verwendet.
Wenn ModelRouter
aktiviert ist, löst der Aufruf der Funktionen pushState
und replaceState
eine Anfrage an PageModelManager
aus, um ein fehlendes Fragment des Modells abzurufen.
Die aktuelle Version der ModelRouter
unterstützt nur die Verwendung von URLs, die auf den tatsächlichen Ressourcenpfad der Einstiegspunkte des Sling-Modells verweisen. Der Einsatz von Vanity-URLs oder Aliasen wird nicht unterstützt.
Der ModelRouter
kann deaktiviert oder so konfiguriert werden, dass eine Liste von regulären Ausdrücken ignoriert wird.
Diese Code-Blöcke veranschaulichen, dass Ihre React- und Angular-Komponenten nichts Spezifisches für Adobe oder AEM benötigen.
Das MapTo
-Hilfsprogramm ist die Verbindung, die eine Abstimmung zwischen Backend- und Frontend-Komponenten ermöglicht:
Weitere Informationen zum Verwenden von MapTo
und Erstellen von SPAs für AEM im Allgemeinen finden Sie im Handbuch „Erste Schritte“ für Ihr ausgewähltes Framework.
Die allgemeine Architektur von AEM einschließlich Umgebungen für Entwicklung, Authoring und Veröffentlichung ändert sich bei Verwendung von SPAs nicht. Es ist jedoch hilfreich zu verstehen, wie die SPA-Entwicklung mit dieser Architektur verbunden ist.
Build-Umgebung
Hier wird die Quelle für die SPA Anwendungsquelle und die Komponentenquelle ausgecheckt.
AEM Author
Inhalte werden im AEM Author erstellt, einschließlich der Authoring-SPAs.
Wenn eine SPA in der Authoring-Umgebung mit dem SPA-Editor bearbeitet wird:
cq-data
-Attribute erstellen kann.cq-data
-Attribute ermöglichen es dem Editor, zusätzliche Seiteninformationen zu laden, sodass er weiß, welche Bearbeitungskonfigurationen für die Komponenten verfügbar sind.AEM Publish
Hier werden die erstellten Inhalte und kompilierten Bibliotheken einschließlich SPA-Anwendungsartefakten, clientlibs und Komponenten für den öffentlichen Gebrauch veröffentlicht.
Dispatcher/CDN
Der Dispatcher dient für Besucherinnen und Besucher der Site als Zwischenspeicherebene von AEM.
In AEM gibt es keine Notwendigkeit, JavaScript-Build-Mechanismen oder das JavaScript selbst auszuführen. AEM hostet lediglich die kompilierten Artefakte aus der SPA-Anwendung.
Einen Überblick darüber, wie eine einfache SPA in AEM strukturiert ist und wie sie funktioniert, finden Sie im Erste-Schritte-Handbuch für React und Angular.
Eine schrittweise Anleitung zum Erstellen einer eigenen SPA finden Sie unter Erste Schritte mit dem AEM-SPA-Editor – WKND-Events-Tutorial.
Weitere Informationen zum dynamischen Modell für die Komponentenzuordnung und dazu, wie es mit SPAs in AEM funktioniert, finden Sie im Artikel Dynamisches Modell für die Komponentenzuordnung bei SPAs.
Wenn Sie SPA in AEM für ein anderes Framework als React oder Angular implementieren möchten oder einfach einen tiefen Einblick in die Funktionsweise des SPA SDK für AEM erhalten möchten, lesen Sie den Abschnitt SPA Blueprint Artikel.