Entwickeln von SPAs für AEM

Letzte Aktualisierung: 2023-10-17

Single Page Applications (SPAs) können ansprechende Erlebnisse für Website-Benutzer bieten. Entwicklungspersonen möchten Sites mit SPA-Frameworks erstellen und Autorinnen bzw. Autoren möchten Inhalte in AEM nahtlos für eine Site bearbeiten, die mit diesen Frameworks erstellt wurde.

Dieser Artikel stellt wichtige Fragen vor, die bei der Beauftragung von Frontend-Entwicklungspersonen mit der Entwicklung einer SPA für AEM zu beachten sind, und gibt einen Überblick über die Architektur von AEM im Hinblick auf die Bereitstellung von SPAs auf AEM.

SPA-Entwicklungsgrundsätze für AEM

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-Entwicklerin bzw. -Entwickler diese allgemeinen Best Practices sowie einige AEM-spezifische Prinzipien befolgen, wird Ihre SPA mit AEM und seinen Inhaltsverfassungsfunktionen zusammenarbeiten.

  • Portabilität: Wie alle anderen Komponenten auch sollten die Komponenten so portabel wie möglich gestaltet werden. Die SPA sollte aus portablen und wiederverwendbaren Komponenten bestehen.
  • AEM verwaltet die Site-Struktur: Die Frontend-Entwicklungsperson erstellt Komponenten und ist für deren interne Struktur verantwortlich, verlässt sich für die Definition der Inhaltsstruktur der Site jedoch auf AEM.
  • Dynamisches Rendering: Alle Rendering-Vorgänge sollten dynamisch sein.
  • Dynamisches Routing: Die SPA ist für das Routing verantwortlich; AEM lauscht darauf und ruft Inhalte auf dieser Basis ab. Jegliches Routing sollte ebenfalls dynamisch sein.

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 ein anderes SPA-Design-Modell in Betracht ziehen.

Portabilität

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.

AEM verwaltet die Site-Struktur

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. Die Struktur der Site gehört jedoch immer AEM.

Diese Kontrolle bedeutet, dass die Frontend-Entwicklungsperson Kundeninhalte vor oder nach dem Einstiegspunkt der Komponenten hinzufügen und innerhalb der Komponente auch Drittanbieter-Aufrufe durchführen kann. Die Frontend-Entwicklungsperson hat jedoch zum Beispiel nicht die volle Kontrolle darüber, wie Komponenten verschachtelt werden.

Dynamisches Rendering

Die SPA sollte sich nur auf dynamisches Rendering von Inhalten stützen. Diese Erwartung ist der Standard, bei dem 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.

Dynamisches Routing

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. Wenn beispielsweise Inhaltsautorinnen oder -autoren bei statischem Routing eine Route ändern oder eine Seite ändern möchten, müssen sie die Frontend-Entwicklungsperson bitten, dies zu tun.

AEM-Projektarchetyp

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.

SPA-Design-Modelle

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 diese Funktionalität nicht unbedingt 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.

Es besteht die Gefahr, dass der Code nicht portabel oder wiederverwendbar ist, 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.

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.

HINWEIS

Obwohl alle Modelle in AEM unterstützt werden, können die Inhaltsautorinnen und -autoren nur dann mit dem Inhalt der SPA in AEM interagieren und ihn bearbeiten, wenn sie das dritte Modell implementieren (und die empfohlenen SPA-Entwicklungsprinzipien befolgen).

Migrieren vorhandener SPAs zu AEM

Wenn Ihre SPA den SPA-Entwicklungsprinzipien für AEM entspricht, funktioniert Ihre SPA in AEM und kann mit dem AEM-SPA-Editor bearbeitet werden.

Führen Sie die folgenden Schritte aus, um Ihre bestehende SPA für die Zusammenarbeit mit AEM bereitzumachen.

  1. Gestalten Sie Ihre JS-Komponenten modular. – Gestalten Sie sie so, dass sie in beliebiger Reihenfolge, Position und Größe gerendert werden können.
  2. Verwenden Sie die vom SDK bereitgestellten Container, um Ihre Komponenten auf dem Bildschirm zu platzieren. – AEM bietet eine Seiten- und Absatzsystemkomponente, die Sie verwenden können.
  3. Erstellen Sie für jede JS-Komponente eine AEM-Komponente. – Die AEM-Komponenten definieren das Dialogfeld und die JSON-Ausgabe.

Anweisungen für Frontend-Entwickler

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 erläutert, die eine Frontend-Entwicklungsperson bei der Entwicklung einer SPA für AEM befolgen muss.

  1. Einigen Sie sich hinsichtlich der Komponenten und ihrer JSON-Modelle

    AEM-Frontend/Backend-Entwicklungspersonen müssen sich auf die erforderlichen Komponenten und ein Modell einigen, damit eine Eins-zu-Eins-Übereinstimmung der SPA-Komponenten mit den Backend-Komponenten besteht.

    AEM-Komponenten sind weiterhin erforderlich, insbesondere um Bearbeitungsdialogfelder bereitzustellen und das Komponentenmodell zu exportieren.

  2. 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.

  3. Implementieren der render()-Methode der Komponente

    Der Frontend-Entwickler implementiert die render()-Methode nach Belieben und kann die Felder der cqModel-Eigenschaft verwenden. Diese Methode gibt das DOM und die HTML-Fragmente aus, die in die Seite eingefügt werden. Diese Methode ist auch die Standardmethode zur Erstellung einer App in React.

  4. 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.

    Diese Zuordnung 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.

  5. 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.

  6. 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.

  7. 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 von ModelRouter unterstützt nur die Verwendung von URLs, die auf den tatsächlichen Ressourcenpfad von Sling-Modell-Einstiegspunkten verweisen. Der Einsatz von Vanity-URLs oder -Aliassen wird nicht unterstützt.

    Der ModelRouter kann deaktiviert oder so konfiguriert werden, dass eine Liste von regulären Ausdrücken ignoriert wird.

AEM-Agnostik

Diese Code-Blöcke veranschaulichen, dass Ihre React- und Angular-Komponenten nichts Spezifisches für Adobe oder AEM benötigen.

  • Alles, was sich in der JavaScript-Komponente befindet, ist AEM-agnostisch.
  • AEM-spezifisch ist jedoch, dass die JS-Komponente mit dem MapTo-Hilfsprogramm einer AEM-Komponente zugeordnet werden muss.

AEM-agnostischer Ansatz

Das MapTo-Hilfsprogramm ist die Verbindung, die eine Abstimmung zwischen Backend- und Frontend-Komponenten ermöglicht:

  • Es teilt dem JS-Container (oder dem JS-Absatzsystem) mit, welche JS-Komponente für das Rendern der einzelnen Komponenten, die in der JSON vorhanden sind, verantwortlich ist.
  • Es wird ein HTML-Datenattribut zum HTML-Code hinzugefügt, das die JS-Komponente rendert, damit der SPA-Editor weiß, welches Dialogfeld dem Autor beim Bearbeiten der Komponente angezeigt werden soll.

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.

AEM-Architektur und SPAs

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.

AEM-Architektur und SPAs

  • Build-Umgebung

    In dieser Umgebung wird die Quelle für die SPA-Anwendung und die Komponentenquelle ausgecheckt.

    • Der NPM-clientlib-Generator erstellt aus dem SPA-Projekt eine Client-Bibliothek.
    • Diese Bibliothek wird von Maven verwendet und vom Maven Build-Plugin zusammen mit der Komponente für AEM Author bereitgestellt.
  • 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:

    1. Die SPA fordert den äußeren HTML-Code an.
    2. Das CSS wird geladen.
    3. Das JavaScript der SPA-Anwendung wird geladen.
    4. Sobald die SPA-Anwendung ausgeführt wird, wird die JSON angefordert, damit die App das DOM der Seite einschließlich der cq-data-Attribute erstellen kann.
    5. Diese 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-Anwendungsartefakte, Client-Bibliotheken und Komponenten, zur öffentlichen Nutzung veröffentlicht.

  • Dispatcher/CDN

    Der Dispatcher dient für Besucherinnen und Besucher der Site als Zwischenspeicherebene von AEM.

    • Anforderungen werden ähnlich wie in der AEM-Authoring-nstanz verarbeitet. Die Seiteninformationen werden jedoch nicht angefordert, da sie nur vom Editor benötigt werden.
    • JavaScript, CSS, JSON und HTML werden zwischengespeichert, wodurch die Seite für eine schnelle Bereitstellung optimiert wird.
HINWEIS

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.

Nächste Schritte

Auf dieser Seite