Komponentenrichtlinien component-guidelines

Die Kernkomponenten folgen modernen Implementierungsmustern, die sich stark von den Foundation-Komponenten unterscheiden.

Diese Seite erklärt diese Muster und wann Sie sie verwenden müssen, um Ihre eigenen autorenfähigen Komponenten zu erstellen. Der erste Abschnitt Allgemeine Komponentenmuster gilt für jede beliebige Komponente, während der zweite Abschnitt Wiederverwendbare Komponentenmuster für Komponenten gilt, die für alle Sites oder Projekte wiederverwendet werden sollen, wie z. B. die Kernkomponenten.

Allgemeine Komponentenmuster general-component-patterns

Die Richtlinien in diesem Abschnitt werden für jede Art von Komponente empfohlen, unabhängig davon, ob die Komponente spezifisch für ein einzelnes Projekt ist oder ob die Komponente für eine breite Wiederverwendung in Sites oder Projekten bestimmt ist.

Konfigurierbare Komponenten configurable-components

Komponenten können Dialogfelder mit einer Vielzahl von Optionen haben. Dies sollte genutzt werden, um Komponenten flexibel und konfigurierbar zu machen und die Implementierung mehrerer Komponenten, die hauptsächlich Variationen voneinander darstellen, zu vermeiden.

Wenn ein Kabelgitter oder ein Design Variationen ähnlicher Elemente enthält, sollten diese Variationen typischerweise nicht als verschiedene Komponenten implementiert werden, sondern als eine Komponente mit Optionen zur Auswahl zwischen den Variationen.

Wenn Sie diesen Schritt weiter durchführen möchten, wenn Komponenten über mehrere Sites oder Projekte hinweg wiederverwendet werden, lesen Sie den Abschnitt Vorkonfigurierbare Funktionen.

Problemtrennung separation-of-concerns

Es empfiehlt sich, die Logik (oder das Modell) einer Komponente getrennt von der Markup-Vorlage (oder der Ansicht) zu halten. Es gibt verschiedene Möglichkeiten, dies zu erreichen. Es wird jedoch empfohlen, Sling-Modelle für die Logik und HTML-Vorlagensprache (HTL) für das Markup zu verwenden, wie dies auch die Kernkomponenten tun.

Sling-Modelle sind eine Reihe von Java-Anmerkungen, um schnell auf benötigte Variablen von POJOs zuzugreifen und daher eine einfache, leistungsstarke und effiziente Möglichkeit, Java-Logik für Komponenten zu implementieren.

HTL wurde als sichere und einfache Vorlagensprache entwickelt, die auf AEM zugeschnitten ist. Es kann viele Formen der Logik aufrufen, was es sehr flexibel macht.

Wiederverwendbare Komponentenmuster reusable-component-patterns

Die Richtlinien in diesem Abschnitt können für jede Art von Komponente ebenfalls verwendet werden. Für Komponenten, die über mehrere Sites oder Projekte hinweg wiederverwendet werden sollen, wie z. B. Kernkomponenten, sind sie jedoch am sinnvollsten. Diese Richtlinien können daher für Komponenten ignoriert werden, die nur auf einer einzelnen Site oder einem einzelnen Projekt verwendet werden.

Vorkonfigurierbare Funktionen pre-configurable-capabilities

Neben dem Bearbeitungsdialogfeld, das von den Seitenautoren verwendet wird, können Komponenten auch ein Dialogfeld „Design“ für Vorlagenautoren haben, um diese vorkonfigurieren zu können. Der Vorlageneditor ermöglicht das Einrichten aller Vorkonfigurationen, die als „Richtlinien“ bezeichnet werden.

Um Komponenten so wiederverwendbar wie möglich zu machen, sollten sie mit aussagekräftigen Optionen zur Vorkonfiguration bereitgestellt werden. Dies ermöglicht das Aktivieren oder Deaktivieren von Funktionen der Komponenten, die den spezifischen Anforderungen verschiedener Sites entsprechen.

Proxy-Komponentenmuster proxy-component-pattern

Da jede Inhalts-Ressource eine sling:resourceType Eigenschaft aufweist, die auf die Komponente verweist, um sie zu rendern, empfiehlt es sich in der Regel, diese Eigenschaften auf Site-spezifische Komponenten zu verweisen, anstatt auf Komponenten zu verweisen, die von mehreren Sites gemeinsam genutzt werden. Dies bietet mehr Flexibilität und verhindert eine Refaktorierung von Inhalten, wenn eine Site ein anderes Verhalten für eine Komponente benötigt, da diese Anpassung dann auf der Site-spezifischen Komponente vorgenommen werden kann und sich nicht auf die anderen Sites auswirkt.

Damit die projektspezifischen Komponenten jedoch keinen Code duplizieren, sollten sie jeweils auf die freigegebene übergeordnete Komponente mit der sling:resourceSuperType-Eigenschaft verweisen. Diese projektspezifischen Komponenten, die überwiegend einfach auf die übergeordneten Komponenten verweisen, werden als „Proxy-Komponenten“ bezeichnet. Proxy-Komponenten können vollständig leer sein, wenn sie die Funktionalität vollständig übernehmen, oder sie können einige Aspekte der Komponente neu definieren.

Komponentenversionierung component-versioning

Komponenten sollten im Laufe der Zeit vollständig kompatibel bleiben. Doch manchmal sind Änderungen, die nicht kompatibel bleiben können, erforderlich. Eine Lösung für diese gegensätzlichen Anforderungen ist die Einführung der Komponentenversionierung durch Hinzufügen einer Nummer in ihrem Ressourcentyppfad und in den voll qualifizierten Java-Klassennamen ihrer Implementierungen. Diese Versionsnummer stellt eine Hauptversion im Sinne der Richtlinien für die semantische Versionierung dar, die nur für Änderungen erhöht wird, die nicht abwärtskompatibel sind.

Inkompatible Änderungen an den folgenden Aspekten von Komponenten führen zu einer neuen Version der Komponenten:

Weitere Informationen finden Sie im Dokument Versionsrichtlinien in GitHub.

Die Komponentenversionierung schafft eine Art Vertrag, der für Upgrades wichtig ist, da sie klärt, wann etwas möglicherweise refaktoriert werden muss. Siehe auch den Abschnitt Upgrade-Kompatibilität von Anpassungen, der erklärt, welche Überlegungen verschiedene Formen von Anpassungen für ein Upgrade erfordern.

Um schmerzhafte Inhaltsmigrationen zu vermeiden, sollten Sie niemals direkt auf versionierte Komponenten aus Inhalts-Ressourcen verweisen. Als Faustregel gilt, dass ein sling:resourceType des Inhalts nie eine Versionsnummer enthalten darf, oder dass bei der Aktualisierung von Komponenten auch der Inhalt refaktoriert werden muss. Am besten lässt sich dies vermeiden, indem Sie dem oben beschriebenen Proxy-Komponentenmuster folgen.

Modellschnittstellen model-interfaces

Dieses Muster bezieht sich auf die Anweisung data-sly-use von HTL, auf eine Java-Schnittstelle zu verweisen, während die Sling-Modell-Implementierung sich selbst auch zum Ressourcentyp der Komponente registriert.

In Kombination mit dem oben beschriebenen Proxy-Komponentenmuster bietet diese Form der doppelten Bindung die folgenden erfreulichen Erweiterungspunkte:

Alles zusammenbringen putting-it-all-together

Im Folgenden finden Sie eine Übersicht über die gesamte Ressourcentyp-Bindungsstruktur, die sich auf die Titel-Kernkomponente bezieht. Es zeigt, wie eine Site-spezifische Proxy-Komponente die Versionierung der Komponenten auflösen lässt, um zu vermeiden, dass die Inhaltsressource eine Versionsnummer enthält. Anschließend wird gezeigt, wie die Datei title.html HTL der Komponente für die Modellschnittstelle verwendet wird, während die Implementierung über Sling Model-Anmerkungen an die bestimmte Version der Komponente gebunden wird.

Im Folgenden finden Sie eine weitere Übersicht, in der keine Details zur Implementierung von POJO angezeigt werden, jedoch die Referenzierung der zugehörigen Vorlagen und Richtlinien.

Die cq:allowedTemplates-Eigenschaft gibt an, welche Vorlagen für eine Site verwendet werden können, und die cq:template informiert für jede Seite, was die zugehörige Vorlage ist. Jede Vorlage besteht aus den folgenden drei Teilen:

AEM-Projektarchetyp aem-project-archetype

Der AEM-Projektarchetyp erstellt ein Adobe Experience Manager-Minimalprojekt als Ausgangspunkt für Ihre eigenen Projekte, einschließlich eines Beispiels für benutzerdefinierte HTL-Komponenten mit SlingModels, um die Logik und ordnungsgemäße Implementierung der Kernkomponenten mit dem empfohlenen Proxy-Muster zu gewährleisten.

Lesen Sie als Nächstes: