Wiederverwenden vorhandener Komponenten

Bevor Sie Zeit in die Erstellung einer völlig neuen Komponente investieren, sollten Sie die Anpassung oder Erweiterung vorhandener Komponenten in Erwägung ziehen. Die Kernkomponenten bieten eine Reihe flexibler, robuster und bewährter produktionstauglicher Komponenten.

Erweitern der Kernkomponenten

Die Kernkomponenten bieten auch klare Anpassungsmuster, die Sie verwenden können, um sie an die Bedürfnisse Ihres eigenen Projekts anzupassen.

Überlagern von Komponenten

Komponenten können mit einer Überlagerung ebenfalls neu definiert werden, die auf der Suchpfadlogik basiert. In diesem Fall wird der Sling Resource Merger nicht ausgelöst und /apps muss die gesamte Überlagerung definieren.

Erweitern von Komponentendialogen

Es ist auch möglich, ein Komponentendialogfeld mithilfe des Sling Resource Mergers zu überschreiben und die Eigenschaft sling:resourceSuperType zu definieren.

Dies bedeutet, dass Sie nur die erforderlichen Unterschiede neu definieren müssen, anstatt das gesamte Dialogfeld neu zu definieren.

Inhaltslogik und Rendering-Markup

Ihre Komponente wird mit HTML gerendert. Ihre Komponente muss den HTML-Code definieren, der notwendig ist, um den erforderlichen Inhalt zu übernehmen und anschließend in der Autoren- und Veröffentlichungsumgebung nach Bedarf zu rendern.

Es empfiehlt sich, den für Markup und Rendering zuständigen Code getrennt von dem Code zu halten, der die Logik zur Auswahl des Komponenteninhalts enthält.

Dieser Ansatz wird durch HTL unterstützt, eine Vorlagensprache, die dazu dient sicherzustellen, dass eine echte Programmiersprache für die Definition der zugrunde liegenden Geschäftslogik genutzt wird. Dieser Mechanismus hebt den Code hervor, der für eine bestimmte Ansicht aufgerufen wird, und lässt bei Bedarf eine spezifische Logik für unterschiedliche Ansichten derselben Komponente zu.

Diese (optionale) Logik kann auf verschiedene Arten implementiert werden und wird von HTL mit bestimmten Befehlen aufgerufen:

  • Verwenden von Java – Die HTL Java Use-API ermöglicht es einer HTL-Datei, auf Hilfsmethoden in einer benutzerdefinierten Java-Klasse zuzugreifen. Dies ermöglicht es Ihnen, Java-Code zu verwenden, um die Logik zum Auswählen und Konfigurieren des Komponenteninhalts zu implementieren.
  • Mit JavaScript – Die HTL JavaScript Use-API ermöglicht es einer HTL-Datei, auf den in JavaScript geschriebenen Hilfs-Code zuzugreifen. Dies ermöglicht es Ihnen, JavaScript-Code zu verwenden, um die Logik zum Auswählen und Konfigurieren des Komponenteninhalts zu implementieren.
  • Verwenden von Client-seitigen Bibliotheken – Moderne Websites beruhen in hohem Maße auf der Client-seitigen Verarbeitung durch einen komplexen JavaScript- und CSS-Code. Weitere Informationen finden Sie im Dokument Verwenden Client-seitiger Bibliotheken in AEM as a Cloud Service.

Komponentenstruktur

Die Struktur einer AEM-Komponente ist leistungsstark und flexibel. Die Hauptbestandteile sind:

Ressourcentyp

Ein zentrales Element der Struktur ist der Ressourcentyp.

  • Die Inhaltsstruktur deklariert Absichten.
  • Der Ressourcentyp implementiert sie.

Dies ist eine Abstraktion, die sicherstellen soll, dass die Absicht unverändert bleibt, auch wenn sich das Erscheinungsbild ändert.

Komponentendefinition

Die Definition einer Komponente lässt sich wie folgt aufschlüsseln:

  • AEM-Komponenten basieren auf Sling.

  • AEM-Komponenten befinden sich unter /libs/core/wcm/components.

  • Projekt- bzw. Website-spezifische Komponenten befinden sich unter /apps/<myApp>/components.

  • AEM-Standardkomponenten sind als cq:Component definiert und haben die folgenden zentralen Elemente:

    • JCR-Eigenschaften – Eine Liste von JCR-Eigenschaften. Diese sind variabel und einige von ihnen können optional sein, obwohl die grundlegende Struktur eines Komponentenknotens, seiner Eigenschaften und untergeordneten Knoten in der cq:Component-Definition festgelegt ist.
    • Ressourcen – Sie definieren statische Elemente, die von der Komponente genutzt werden.
    • Skripte – Sie werden verwendet, um das Verhalten der entstandenen Instanz der Komponente zu implementieren.

Wichtige Eigenschaften

  • Stammknoten:

    • <mycomponent> (cq:Component) – Hierarchieknoten der Komponente.
  • Wichtige Eigenschaften:

    • jcr:title – Komponententitel; wird beispielsweise als Titel genutzt, wenn die Komponente im Komponenten-Browser oder in der Komponentenkonsole aufgeführt wird.
    • jcr:description – Beschreibung der Komponente; wird als Mouseover-Hinweis im Komponenten-Browser oder in der Komponentenkonsole genutzt.
    • Weitere Informationen finden Sie im Abschnitt Komponentensymbol.
  • Wichtige untergeordnete Knoten:

    • cq:editConfig (cq:EditConfig) – Definiert die Bearbeitungseigenschaften der Komponente und ermöglicht es, dass die Komponente im Komponenten-Browser aufgeführt wird.
      • Wenn die Komponente über ein Dialogfeld verfügt, wird sie automatisch im Komponenten-Browser oder Sidekick aufgeführt, selbst wenn die cq:editConfig nicht vorhanden ist.
    • cq:childEditConfig (cq:EditConfig) – Steuert Aspekte der Autoren-Benutzeroberfläche für untergeordnete Komponenten, die keine eigene cq:editConfig definieren.
    • cq:dialog (nt:unstructured) – Dialogfeld für diese Komponente. Definiert die Oberfläche, über die Benutzer die Komponente konfigurieren und/oder Inhalte bearbeiten können.
    • cq:design_dialog (nt:unstructured) – Design-Bearbeitung für diese Komponente

Komponentensymbol

Das Symbol oder die Abkürzung für die Komponente wird mit JCR-Eigenschaften der Komponente definiert, wenn die Komponente vom Entwickler erstellt wird. Diese Eigenschaften werden in der folgenden Reihenfolge ausgewertet und die erste erkannte gültige Eigenschaft wird verwendet.

  1. cq:icon – Zeichenfolgeneigenschaft, die auf ein Standardsymbol in der Bibliothek der Coral-Benutzeroberfläche verweist, das im Komponenten-Browser angezeigt werden soll.

    • Verwenden Sie den Wert des HTML-Attributs des Coral-Symbols.
  2. abbreviation – Zeichenfolgeneigenschaft, die die Abkürzung des Komponentennamens im Komponenten-Browser anpasst.

    • Die Abkürzung sollte auf zwei Zeichen beschränkt sein.

    • Bei einer leeren Zeichenfolge wird die Abkürzung aus den ersten beiden Buchstaben der Eigenschaft jcr:title gebildet.

      • Beispiel: „Gr“ für „Grafik“
      • Zum Erstellen der Abkürzung wird der lokalisierte Titel verwendet.
    • Die Abkürzung wird nur übersetzt, wenn die Komponente die Eigenschaft abbreviation_commentI18n aufweist, die dann als Anweisung für eine Übersetzung genutzt wird.

  3. cq:icon.png oder cq:icon.svg – Symbol für diese Komponente, das im Komponenten-Browser angezeigt wird.

    • Symbole von Standardkomponenten haben eine Größe von 20 x 20 Pixeln.
      • Größere Symbole werden (Client-seitig) herunterskaliert.
    • Die empfohlene Farbe ist rgb(112, 112, 112) > #707070.
    • Der Hintergrund von Symbolen von Standardkomponenten ist transparent.
    • Es werden nur .png- und .svg-Dateien unterstützt.
    • Beim Importieren aus dem Dateisystem über das Eclipse-Plug-in müssen die Dateinamen nach folgendem Schema geändert werden: z. B. _cq_icon.png oder _cq_icon.svg.
    • Wenn beide Formate vorliegen, hat .png Vorrang vor .svg.

Wenn keine der o. g. Eigenschaften (cq:icon, abbreviation, cq:icon.png oder cq:icon.svg) bei der Komponente gefunden wird:

  • Das System sucht nach denselben Eigenschaften bei den übergeordneten Komponenten, die der Eigenschaft sling:resourceSuperType folgen.
  • Wenn auf der Ebene der übergeordneten Komponente nichts oder eine leere Abkürzung gefunden wird, erstellt das System die Abkürzung aus den ersten beiden Zeichen der Eigenschaft jcr:title der aktuellen Komponente.

Um die Vererbung von Symbolen von übergeordneten Komponenten zu deaktivieren, legen Sie eine leere Eigenschaft abbreviation für die Komponente fest. Das Standardverhalten wird daraufhin erneut aktiviert.

Die Komponentenkonsole zeigt an, wie das Symbol für eine bestimmte Komponente definiert ist.