AEM-Komponenten – Grundlagen aem-components-the-basics

Was genau soll die neue Komponente tun?

• Eine eindeutige Spezifikation hilft in allen Phasen der Entwicklung, des Testings und der Übergabe.

  Details können sich im Laufe der Zeit ändern, woraufhin die Spezifikation jedoch aktualisiert werden kann (Änderungen sollten jedoch ebenso dokumentiert werden).

Müssen Sie die Komponente komplett neu entwickeln oder können Sie die Grundlagen von einer vorhandenen Komponente übernehmen?

• Sie müssen das Rad nicht neu erfinden.
• AEM bietet mehrere Mechanismen, um Details von anderen Komponentendefinitionen zu erben und zu erweitern, darunter Überschreiben, Überlagerung und den Sling Resource Merger.

Benötigt die Komponente eine Logik zur Auswahl/Bearbeitung des Inhalts?

• Die Logik sollte getrennt von der Ebene der Benutzeroberfläche aufbewahrt werden. HTL dient dazu, dies sicherzustellen.

Benötigt Ihre Komponente eine CSS-Formatierung?

• Eine CSS-Formatierung sollte getrennt von den Komponentendefinitionen aufbewahrt werden. Legen Sie Konventionen für die Benennung der HTML-Elemente fest, damit Sie sie über externe CSS-Dateien modifizieren können.

Welche Sicherheitsaspekte sollte ich berücksichtigen?

• Weitere Informationen finden Sie unter Sicherheits-Checkliste – Best Practices für die Entwicklung.

Touch-optimierte Benutzeroberfläche
Die Standardbenutzeroberfläche wurde in AEM 5.6.0 als Vorschau eingeführt und in 6.x erweitert. Sie basiert auf dem einheitlichen Benutzererlebnis für die Adobe Marketing Cloud und verwendet dabei die zugrunde liegenden Technologien von Coral-Benutzeroberfläche und Granite-Benutzeroberfläche.

Klassische Benutzeroberfläche
Benutzerschnittstelle basierend auf der ExtJS-Technologie, die mit CQ 5.1 eingeführt wurde.

Seite:

• AEM verfügt über die Komponente Seite ( cq:Page).
• Dies ist ein spezifischer Ressourcentyp, der für das Content Management wichtig ist.
  • Eine Seite entspricht einer Webseite mit Inhalten für Ihre Website.

Absatzsysteme:

• Das Absatzsystem ist ein wichtiger Teil einer Website, da es eine Liste von Absätzen verwaltet. Sie wird verwendet, um die einzelnen Komponenten zu speichern und zu strukturieren, die den tatsächlichen Inhalt enthalten.
• Sie können Absätze im Absatzsystem erstellen, verschieben, kopieren und löschen.
• Sie können auch die Komponenten auswählen, die in einem bestimmten Absatzsystem verwendet werden können.
• In einer Standardinstanz stehen diverse Absatzsysteme zur Verfügung (z. B parsys, [responsivegrid](/docs/experience-manager-64/sites-authoring/responsive-layout.md)).

AEM-Komponenten basieren auf Sling.

AEM Komponenten befinden sich (in der Regel) unter:

• HTL: /libs/wcm/foundation/components
• JSP: /libs/foundation/components

Projekt- bzw. Website-spezifische Komponenten befinden sich (in der Regel) unter:

• /apps/<myApp>/components

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

• JCR-Eigenschaften:

  Eine Liste von JCR-Eigenschaften. Sie 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.

Stammknoten:

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

Wichtige Eigenschaften:

• jcr:title – Komponententitel; wird beispielsweise als Kennzeichnung genutzt, wenn die Komponente im Komponenten-Browser oder Sidekick aufgeführt wird

• jcr:description – Beschreibung der Komponente; kann als Mouseover-Hinweis im Komponenten-Browser oder Sidekick genutzt werden

• Klassische Benutzeroberfläche:

  • icon.png – Symbol für diese Komponente
  • thumbnail.png – Bild, das angezeigt wird, wenn diese Komponente im Absatzsystem aufgeführt wird

• Touch-optimierte Benutzeroberfläche

  • Siehe Abschnitt . Komponentensymbol in der Touch-optimierten Benutzeroberfläche für Details.

Wichtige untergeordnete Knoten:

• cq:editConfig (cq:EditConfig) – Definiert die Bearbeitungseigenschaften der Komponente und ermöglicht es, dass die Komponente im Komponenten-Browser oder Sidekick aufgeführt wird.

  Hinweis: 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.

• Touch-optimierte Benutzeroberfläche:

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

• Klassische Benutzeroberfläche:

  • dialog ( cq:Dialog) – Dialogfeld für diese Komponente. Definiert die Oberfläche, über die Benutzer die Komponente konfigurieren und/oder Inhalte bearbeiten können.
  • design_dialog ( cq:Dialog) – Design-Bearbeitung für diese Komponente.

HTL ( /libs/wcm/foundation/components/text)

JSP ( /libs/foundation/components/text)

jcr:title – Titel der Komponente; dient zur Identifizierung der Komponente, z. B. in der Komponentenliste im Komponenten-Browser oder Sidekick

jcr:description – Beschreibung der Komponente; kann als Mouseover-Hinweis in der Komponentenliste im Sidekick genutzt werden

sling:resourceSuperType – gibt den Pfad der Vererbung bei der Erweiterung einer Komponente an (durch Überschreiben einer Definition)

cq:editConfig ( cq:EditConfig) – steuert visuelle Aspekte; definiert z. B. das Aussehen einer Leiste oder eines Widgets oder fügt angepasste Steuerelemente hinzu

cq:childEditConfig ( cq:EditConfig) – steuert die visuellen Aspekte für untergeordnete Komponenten, die keine eigenen Definitionen aufweisen

Touch-optimierte Benutzeroberfläche:

• cq:dialog ( nt:unstructured) – definiert das Dialogfeld für die Bearbeitung von Inhalten dieser Komponente
• cq:design_dialog ( nt:unstructured) – legt die Design-Bearbeitungsoptionen für diese Komponente fest

Klassische Benutzeroberfläche:

• dialog ( cq:Dialog) – definiert das Dialogfeld zum Bearbeiten von Inhalten dieser Komponente (speziell für die klassische Benutzeroberfläche)
• design_dialog ( cq:Dialog) – legt die Design-Bearbeitungsoptionen für diese Komponente fest
• icon.png – Grafikdatei, die als Symbol für die Komponente im Sidekick genutzt werden soll
• thumbnail.png – Grafikdatei, die als Miniaturansicht der Komponente beim Ziehen aus dem Sidekick genutzt werden soll

Touch-optimierte Benutzeroberfläche

• cq:dialog ( nt:unstructured) Knoten:

  • definieren das Dialogfeld für die Bearbeitung von Inhalten dieser Komponente

  • speziell für die Touch-optimierte Benutzeroberfläche

  • werden mithilfe von Granite-UI-Komponenten definiert

  • weisen die Eigenschaft sling:resourceType als standardmäßige Sling-Inhaltsstruktur auf

  • können die Eigenschaft helpPath aufweisen, um die kontextabhängige Hilferessource festzulegen (absoluter oder relativer Pfad), auf die bei Auswahl des Hilfesymbols (das Fragezeichen-Symbol) zugegriffen wird.

    • Bei standardmäßigen Komponenten verweist diese Eigenschaft häufig auf eine Seite in der Dokumentation.
    • Wenn kein helpPath festgelegt ist, wird die Standard-URL (Übersichtsseite der Dokumentation) angezeigt.

In diesem Dialogfeld werden einzelne Felder definiert:

Klassische Benutzeroberfläche

• dialog ( cq:Dialog) Knoten

  • definieren das Dialogfeld für die Bearbeitung von Inhalten dieser Komponente

  • speziell für die klassische Benutzeroberfläche

  • werden mit ExtJS-Widgets definiert

  • weisen die Eigenschaft xtype auf, die auf ExtJS verweist

  • können die Eigenschaft helpPath aufweisen, um die kontextabhängige Hilferessource festzulegen (absoluter oder relativer Pfad), auf die bei Klicken auf die Schaltfläche Hilfe zugegriffen wird.

    • Bei standardmäßigen Komponenten verweist diese Eigenschaft häufig auf eine Seite in der Dokumentation.
    • Wenn kein helpPath festgelegt ist, wird die Standard-URL (Übersichtsseite der Dokumentation) angezeigt.

In diesem Dialogfeld werden einzelne Felder definiert:

Innerhalb eines klassischen Dialogfelds:

• können Sie Dialogfeld wie cq:Dialog erstellen, die eine einzige Registerkarte aufweisen, wie in der Text-Komponente. Wenn Sie mehrere Registerkarten benötigen, wie in der Textbild-Komponente, können Sie das Dialogfeld als cq:TabPanel definieren.
• wird eine cq:WidgetCollection ( items) genutzt, um eine Basis für Eingabefelder (cq:Widget) oder weitere Registerkarten (cq:Widget) bereitzustellen. Diese Hierarchie kann erweitert werden.

Touch-optimierte Benutzeroberfläche

Klassische Benutzeroberfläche

Die Definition weist (bei beiden Benutzeroberflächen) die Eigenschaft name= ./jcr:title

• /libs/foundation/components/title/cq:dialog/content/items/column/items/title
• /libs/foundation/components/title/dialog/items/title

Innerhalb des Inhalts wird dadurch die Eigenschaft jcr:title erstellt, die den Inhalt des Autors enthält.

Ressourcentyphierarchie

Diese wird verwendet, um Komponenten mit der sling:resourceSuperType-Eigenschaft zu erweitern. Dies aktiviert die Vererbung für die Komponente. Beispielsweise erbt eine Textkomponente verschiedene Attribute von der Standardkomponente.

• Skripte (von Sling aufgelöst)
• Dialogfelder
• Beschreibungen (einschließlich Miniaturansichten, Symbole usw.)

Container-Hierarchie

Hiermit werden Konfigurationseinstellungen an untergeordnete Komponenten weitergegeben. Gängig ist dies vor allem bei parsys-Szenarien.

So können Sie beispielsweise Konfigurationseinstellungen für die Schaltflächen auf der Bearbeitungsleiste, das Layout von Steuerungen (Bearbeitungsleiste, Rollover) oder von Dialogfeldern (eingebunden, unverankert) auf der übergeordneten Komponente definieren und an die untergeordneten Komponenten übergeben.

Konfigurationseinstellungen (für die Bearbeitungsfunktion) in cq:editConfig und cq:childEditConfig werden weitergegeben.

Einschlusshierarchie

Diese Hierarchie wird zur Laufzeit durch eine Folge an Einschlüssen eingeführt.

Diese Hierarchie wird vom Designer verwendet, der als Basis für die verschiedenen Designaspekte des Rendering fungiert; einschließlich Layout-Angaben, CSS-Informationen, verfügbaren Komponenten in einem parsys usw.

cq:editConfig-Knoteneigenschaften:

• cq:actions ( String array): legt die Aktionen fest, die für die Komponente durchgeführt werden

• cq:layout ( String): definiert, wie die Komponente in der klassischen Benutzeroberfläche bearbeitet wird

• cq:dialogMode ( String): definiert, wie das Komponentendialogfeld in der klassischen Benutzeroberfläche geöffnet wird

  • In der Touch-optimierten Benutzeroberfläche sind die Dialogfelder im Desktop-Modus immer unverankert und werden im mobilen Modus immer im Vollbild geöffnet.

• cq:emptyText ( String): definiert den Text, der angezeigt wird, wenn keine visuellen Inhalte vorhanden sind

• cq:inherit ( Boolean): legt fest, ob fehlende Werte von der Komponente geerbt werden, von der die Vererbung erfolgt

• dialogLayout (String): legt fest, wie das Dialogfeld geöffnet werden soll

cq:editConfig Untergeordnete -Knoten:

• cq:dropTargets (Knotentyp nt:unstructured): definiert eine Liste von Ablagezielen, die eine Ablage von einem Asset aus dem Content Finder annehmen können.

  • Mehrere Ablageziele sind nur in der klassischen Benutzeroberfläche verfügbar.
  • In der Touch-optimierten Benutzeroberfläche ist nur ein einziges Ablageziel zulässig.

• cq:actionConfigs (Knotentyp nt:unstructured): definiert eine Liste mit neuen Aktionen, die an die cq:actions-Liste angehängt wird

• cq:formParameters (Knotentyp nt:unstructured): definiert zusätzliche Parameter, die zum Dialogfeldformular hinzugefügt werden

• cq:inplaceEditing (Knotentyp cq:InplaceEditingConfig): definiert eine Kontextbearbeitungsfunktion für die Komponente

• cq:listeners (Knotentyp cq:EditListenersConfig): Legt fest, was geschieht, bevor oder nachdem eine Aktion auf der Komponente stattfindet.

Um nach einer Eigenschaft des Knotens cq:editConfig, z. B. cq:actions, zu suchen, können Sie das Abfrage-Tool in CRXDE Lite nutzen und mit der folgenden XPath-Abfragezeichenfolge suchen:

//element(cq:editConfig, cq:EditConfig)[@cq:actions]

Um einen untergeordneten Knoten von cq:editConfig zu suchen, z. B. nach cq:dropTargets mit dem Typ cq:DropTargetConfig, können Sie das Abfrage-Tool in CRXDE Lite nutzen und mit der folgenden XPath-Abfragezeichenfolge suchen:

//element(cq:dropTargets, cq:DropTargetConfig)

ein Trennzeichen, definiert durch den xtype tbseparator;

• Dies wird nur von der klassischen Benutzeroberfläche verwendet.
• Diese Definition wird von der Touch-optimierten Benutzeroberfläche ignoriert, weil xtypes ignoriert werden (und Trennzeichen unnötig sind, da die Aktionssymbolleiste in der Touch-optimierten Benutzeroberfläche anders aufgebaut ist).

eine Schaltfläche Manage comments (Kommentare verwalten), die die Handler-Funktion CQ_collab_forum_openCollabAdmin() ausführt.