Wenn Sie neue Komponenten entwickeln, müssen Sie die Grundlagen ihrer Struktur und Konfiguration kennen.
Dazu müssen Sie den theoretischen Hintergrund kennenlernen und sich mit den vielfältigen Komponenten-Implementierungen in einer standardmäßigen AEM-Instanz vertraut machen. Der zuletzt genannte Ansatz wird ein Stück weit durch die Tatsache erschwert, dass AEM zwar standardmäßig eine neue, moderne Touch-optimierte Benutzeroberfläche einsetzt, die klassische Benutzeroberfläche aber nach wie vor unterstützt.
In diesem Abschnitt werden zentrale Konzepte und Schwierigkeiten erläutert. Er bietet so einen guten Einstieg in die Entwicklung eigener Komponenten.
Bevor Sie mit der Konfiguration oder dem Code Ihrer Komponente beginnen, sollten Sie sich fragen:
Bevor es um die Entwicklung von Komponenten geht, müssen Sie wissen, welche Benutzeroberfläche Ihre Autoren verwenden:
Weitere Informationen finden Sie unter Benutzeroberflächen-Empfehlungen für Kunden.
Komponenten können je nach Implementierung die Touch-optimierte Benutzeroberfläche, die klassische oder beide Versionen unterstützen. Wenn Sie sich eine Standardinstanz ansehen, werden Ihnen auch sofort einsatzbereite Komponenten angezeigt, die ursprünglich für die klassische Benutzeroberfläche oder die touchfähige Benutzeroberfläche oder beides entwickelt wurden.
Daher werden auf dieser Seite die Grundlagen und die Erkennungsmerkmale beider Versionen abgedeckt.
Adobe empfiehlt die Nutzung der touchfähigen Benutzeroberfläche, um von der neuesten Technologie zu profitieren. AEM Modernisierung Toolscan erleichtert die Migration.
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. Diese (optionale) Logik wird von HTL über einen speziellen Befehl aufgerufen. Dieser Mechanismus kennzeichnet den Code, der für eine bestimmte Ansicht aufgerufen wird, und lässt bei Bedarf eine spezifische Logik für unterschiedliche Ansichten derselben Komponente zu.
HTL ist eine HTML-Vorlagensprache, die mit AEM 6.0 eingeführt wurde.
Die Frage, ob Sie bei der Entwicklung eigener Komponenten HTL oder JSP (Java Server Pages) nutzen sollten, ist leicht zu beantworten – immerhin ist HTL nun die empfohlene Skriptsprache für AEM.
Sie können sowohl HTL als auch JSP für die Entwicklung von Komponenten für die klassische wie die Touch-optimierte Benutzeroberfläche verwenden. Zwar wird häufig angenommen, dass HTL nur für die Touch-optimierte und JSP für die klassische Benutzeroberfläche ist, doch diese Vermutung ist falsch und wohl auf die Tatsache zurückzuführen, dass die Touch-optimierte Benutzeroberfläche und HTL ungefähr zur selben Zeit in AEM integriert wurden. Da HTL nun die empfohlene Sprache ist, wird sie für neue Komponenten verwendet, die meistens für die Touch-optimierte Benutzeroberfläche ausgelegt sind.
Ausnahme hiervon sind die Foundation-Formularfelder der Granite-Benutzeroberfläche (wie sie in Dialogfeldern verwendet werden). Für sie ist die Verwendung von JSP erforderlich.
Informationen zum Erstellen eigener Komponenten für die entsprechende Benutzeroberfläche finden Sie (nach dem Lesen dieser Seite) unter:
Eine schnelle Möglichkeit für den Einstieg ist das Kopieren einer vorhandenen Komponente und das anschließende Vornehmen der gewünschten Änderungen. Informationen dazu, wie Sie Ihre eigenen Komponenten erstellen und sie zum Absatzsystem hinzufügen, finden Sie unter:
Die Komponenten, die Inhalte rendern, müssen auf derselben AEM-Instanz bereitgestellt werden wie die Inhalte. Daher müssen alle Komponenten, die zum Verfassen und Rendern von Seiten auf der Autoreninstanz genutzt werden, auf der Veröffentlichungsinstanz bereitgestellt werden. Wenn sie bereitgestellt sind, stehen diese Komponenten zum Rendern aktivierter Seiten zur Verfügung.
Mit den folgenden Tools können Sie Ihre Komponenten in die Veröffentlichungsinstanz verschieben:
Mit diesen Mechanismen können Sie Ihre Komponente auch zwischen anderen Instanzen verschieben, z. B. von der Entwicklungs- zur Testinstanz.
Seite:
cq:Page
).Absatzsysteme:
parsys
, [responsivegrid](/docs/experience-manager-65/sites-authoring/responsive-layout.md)
).Die Struktur einer AEM-Komponente ist leistungsstark und flexibel. Die wichtigsten Aspekte sind:
Ein zentrales Element der Struktur ist der Ressourcentyp.
Dies ist eine Abstraktion, die sicherstellen soll, dass die Intention unverändert bleibt, auch wenn sich das Erscheinungsbild ändert.
Die Definition einer Komponente lässt sich wie folgt aufschlüsseln:
AEM-Komponenten basieren auf Sling.
AEM-Komponenten befinden sich (in der Regel) unter:
/libs/wcm/foundation/components
/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; diese Variablen sind variabel und einige können optional sein, obwohl die grundlegende Struktur eines Komponenten-Knotens, seine Eigenschaften und Unterknoten durch die cq:Component
-Definition definiert werden.
Ressourcen:
Diese definieren Statische Element, die von der Komponente verwendet werden.
Skripte:
werden verwendet, um das Verhalten der resultierenden Instanz der Komponente zu implementieren.
Stammknoten:
<mycomponent> (cq:Component)
- Hierarchie-Knoten 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 wirdTouch-optimierte Benutzeroberfläche
Wichtige untergeordnete Knoten:
cq:editConfig (cq:EditConfig)
- Definiert die Bearbeitungseigenschaften der Komponente und ermöglicht die Anzeige der Komponente im Komponenten-Browser oder Sidekick.
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 die Aspekte der Autorenbenutzeroberfläche für untergeordnete Komponenten, die keine eigenen definieren cq:editConfig
.
Touch-optimierte Benutzeroberfläche:
cq:dialog
( nt:unstructured
) - Dialog 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
) - Designbearbeitung für diese KomponenteKlassische Benutzeroberfläche:
dialog
( cq:Dialog
) - Dialog für diese Komponente. Definiert die Oberfläche, über die Benutzer die Komponente konfigurieren und/oder Inhalte bearbeiten können.design_dialog
( cq:Dialog
) - Designbearbeitung für diese Komponente.Das Symbol oder die Abkürzung für die Komponente wird über die 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.
cq:icon
- String-Eigenschaft, die auf ein Standardsymbol in der Coral UI-Bibliothek verweist und im Komponenten-Browser angezeigt wird
abbreviation
- String-Eigenschaft zum Anpassen der Abkürzung des Komponentennamens im Komponenten-Browser
jcr:title
gebildet.
abbreviation_commentI18n
aufweist, die dann als Anweisung für eine Übersetzung genutzt wird.cq:icon.png
oder cq:icon.svg
- Symbol für diese Komponente, das im Komponenten-Browser angezeigt wird
.png
und .svg
unterstützt._cq_icon.png
oder _cq_icon.svg
gekennzeichnet werden..png
hat Vorrang, .svg
wenn beide vorhanden sindWenn keine der oben genannten Eigenschaften ( cq:icon
, abbreviation
, cq:icon.png
oder cq:icon.svg
) für die Komponente gefunden wird:
sling:resourceSuperType
folgen.jcr:title
-Eigenschaft 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 wird.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" x="0px" y="0px"
width="20px" height="20px" viewBox="0 0 20 20" enable-background="new 0 0 20 20" xml:space="preserve">
<ellipse cx="5" cy="5" rx="3" ry="3" fill="#707070"/>
<ellipse cx="15" cy="5" rx="4" ry="4" fill="#707070"/>
<ellipse cx="5" cy="15" rx="5" ry="5" fill="#707070"/>
<ellipse cx="15" cy="15" rx="4" ry="4" fill="#707070"/>
</svg>
Viele der Knoten/Eigenschaften, die für die Definition einer Komponente erforderlich sind, sind in beiden Benutzeroberflächen zu finden. Die Unterschiede bleiben unabhängig, sodass Ihre Komponente in beiden Umgebungen funktioniert.
Eine Komponente ist ein Knoten des Typs cq:Component
mit den folgenden Eigenschaften und untergeordneten Knoten:
Name |
Typ |
Beschreibung |
. |
cq:Component |
Aktuelle Komponente. Eine Komponente ist vom Knotentyp cq:Component . |
componentGroup |
String |
Gruppe, aus der die Komponente im Komponenten-Browser (Touch-optimierte Benutzeroberfläche) oder Sidekick (klassische Benutzeroberfläche) ausgewählt werden kann. Ein Wert von .hidden wird für Komponenten verwendet, die nicht über die Benutzeroberfläche ausgewählt werden können, wie z. B. die Absatzsysteme. |
cq:isContainer |
Boolean |
Gibt an, ob es sich bei der Komponente um eine Containerkomponente handelt, die andere Komponenten wie ein Absatzsystem enthalten kann. |
cq:dialog |
nt:unstructured |
Definition des Bearbeitungsdialogfelds für die Touch-optimierte Benutzeroberfläche |
dialog |
cq:Dialog |
Definition des Bearbeitungsdialogfelds für die klassische Benutzeroberfläche |
cq:design_dialog |
nt:unstructured |
Definition des Designdialogfelds für die Touch-optimierte Benutzeroberfläche |
design_dialog |
cq:Dialog |
Definition des Designdialogfelds für die klassische Benutzeroberfläche |
dialogPath |
String |
Pfad zu einem Dialogfeld, wenn die Komponente keinen Dialogfeldknoten aufweist |
cq:cellName |
String |
Wenn diese Eigenschaft festgelegt ist, dient sie als Zellen-ID. Weitere Informationen finden Sie im Artikel Erstellung von Design-Zellen-IDs in der Wissensdatenbank. |
cq:childEditConfig |
cq:EditConfig |
Wenn die Komponente ein Container ist, z. B. ein Absatzsystem, steuert diese Eigenschaft die Bearbeitungskonfiguration der untergeordneten Knoten. |
cq:editConfig |
cq:EditConfig |
Bearbeitungskonfiguration der Komponente |
cq:htmlTag |
nt:unstructured |
Gibt zusätzliche Tag-Attribute zurück, die zum umgebenden HTML-Tag hinzugefügt werden. Ermöglicht das Hinzufügen von Attributen zu den automatisch generierten div-Tags. |
cq:noDecoration |
Boolean |
Bei „true“ wird die Komponente nicht mit automatisch erstellten div- und CSS-Klassen gerendert. |
cq:template |
nt:unstructured |
Wenn vorhanden, wird dieser Knoten als Inhaltsvorlage genutzt, wenn die Komponente vom Komponenten-Browser oder Sidekick hinzugefügt wird. |
cq:templatePath |
String |
Pfad zu einem Knoten, der als Inhaltsvorlage genutzt wird, wenn die Komponente vom Komponenten-Browser oder Sidekick hinzugefügt wird. Es muss sich hierbei um einen absoluten Pfad handeln, keinen relativen zum Komponentenknoten. Wenn Sie keine bereits an anderer Stelle verfügbaren Inhalte wiederverwenden möchten, ist dies nicht erforderlich und cq:template ausreichend (siehe unten). |
jcr:created |
Date |
Datum der Erstellung der Komponente |
jcr:description |
String |
Beschreibung der Komponente |
jcr:title |
String |
Titel der Komponente |
sling:resourceSuperType |
String |
Wenn dieser Wert festgelegt ist, erbt die Komponente von dieser Komponente. |
virtual |
sling:Folder |
Aktiviert das Erstellen von virtuellen Komponenten. Ein Beispiel finden Sie in der Komponente "Kontakt" unter:/libs/foundation/components/profile/form/contact |
<breadcrumb.jsp> |
nt:file |
Skriptdatei |
icon.png |
nt:file |
Symbol der Komponente, wird neben dem Titel im Sidekick angezeigt |
thumbnail.png |
nt:file |
Optionale Miniaturansicht, die angezeigt wird, wenn die Komponente aus dem Sidekick an ihre Position gezogen wird. |
In der Text-Komponente (beide Versionen) finden sich die folgenden Elemente:
HTL ( /libs/wcm/foundation/components/text
)
JSP ( /libs/foundation/components/text
)
Zu den wichtigen Eigenschaften gehören:
jcr:title
– Titel der Komponente; dient zur Identifizierung der Komponente, z. B. in der Komponentenliste im Komponenten-Browser oder Sidekickjcr:description
– Beschreibung der Komponente; kann als Mouseover-Hinweis in der Komponentenliste im Sidekick genutzt werdensling:resourceSuperType
– gibt den Pfad der Vererbung bei der Erweiterung einer Komponente an (durch Überschreiben einer Definition)Zu den wichtigen untergeordneten Knoten gehören:
cq:editConfig
( cq:EditConfig
) - dies kontrolliert visuelle Aspekte; Sie kann beispielsweise das Erscheinungsbild einer Leiste oder eines Widgets definieren oder benutzerdefinierte Steuerelemente hinzufügencq:childEditConfig
( cq:EditConfig
) - Diese Funktion steuert die visuellen Aspekte für untergeordnete Komponenten, die keine eigenen Definitionen haben.cq:dialog
( nt:unstructured
) - definiert das Dialogfeld zum Bearbeiten des Inhalts dieser Komponentecq:design_dialog
( nt:unstructured
) - gibt die Entwurfsbearbeitungsoptionen für diese Komponente andialog
( cq:Dialog
) - Definiert das Dialogfeld zum Bearbeiten des Inhalts dieser Komponente (spezifisch für die klassische Benutzeroberfläche)design_dialog
( cq:Dialog
) - gibt die Entwurfsbearbeitungsoptionen für diese Komponente anicon.png
– Grafikdatei, die als Symbol für die Komponente im Sidekick genutzt werden sollthumbnail.png
– Grafikdatei, die als Miniaturansicht der Komponente beim Ziehen aus dem Sidekick genutzt werden sollDialogfelder sind ein wichtiges Element einer Komponente: Sie stellen den Autoren eine Oberfläche für die Konfiguration und für Eingaben für diese Komponente bereit.
Je nach Komplexität der Komponente benötigt das Dialogfeld eine Registerkarte oder mehrere, um das Dialogfeld übersichtlich zu gestalten und die Eingabefelder zu ordnen.
Dialogdefinitionen sind spezifisch für jede Benutzeroberfläche.
Touch-optimierte Benutzeroberfläche
cq:dialog
( nt:unstructured
) nodes:
sling:resourceType
als standardmäßige Sling-Inhaltsstruktur verfügenhelpPath
aufweisen, um die kontextabhängige Hilferessource festzulegen (absoluter oder relativer Pfad), auf die bei Auswahl des Hilfesymbols ausgewählt ist.
helpPath
festgelegt ist, wird die Standard-URL (Übersichtsseite der Dokumentation) angezeigt.In diesem Dialogfeld werden einzelne Felder definiert:
Klassische Benutzeroberfläche
dialog
( cq:Dialog
) nodes
xtype
auf, die auf ExtJS verweisthelpPath
aufweisen, um die kontextabhängige Hilferessource festzulegen (absoluter oder relativer Pfad), auf die bei Klicken auf die Schaltfläche Hilfe zugegriffen wird.
helpPath
festgelegt ist, wird die Standard-URL (Übersichtsseite der Dokumentation) angezeigt.In diesem Dialogfeld werden einzelne Felder definiert:
In einem klassischen Dialogfeld:
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.cq:WidgetCollection
( items
) wird verwendet, um eine Basis für Eingabefelder ( cq:Widget
) oder weitere Registerkarten ( cq:Widget
) bereitzustellen. Diese Hierarchie kann erweitert werden.Designdialogfelder ähneln den Dialogfeldern, die zum Bearbeiten und Konfigurieren von Inhalten genutzt werden. Sie stellen die Oberfläche für Autoren zum Konfigurieren bereit und liefern Designinformationen für diese Komponente.
Designdialogfelder sind im Designmodus verfügbar, wobei sie nicht für alle Komponenten benötigt werden. Beispielsweise verfügen sowohl Titel als auch Bild über Designdialogfelder, Text dagegen nicht.
Das Designdialogfeld für das Absatzsystem (z. B. parsys) ist ein Sonderfall: Benutzer können damit andere Komponenten festlegen, die auf der Seite zur Auswahl (über den Komponenten-Browser oder Sidekick) verfügbar sein sollen.
Nachdem eine Komponente definiert wurde, muss sie zur Verwendung bereitgestellt werden. Um eine Komponente zur Verwendung in einem Absatzsystem bereitzustellen, haben Sie zwei Möglichkeiten:
Öffnen Sie den Designmodus für eine Seite und aktivieren Sie die benötigte Komponente.
Fügen Sie die benötigte(n) Komponente(n) zur Eigenschaft components
der Vorlagendefinition unter folgendem Pfad hinzu:
/etc/designs/<*yourProject*>/jcr:content/<*yourTemplate*>/par
Ein Beispiel finden Sie unter:
/etc/designs/geometrixx/jcr:content/contentpage/par
Wenn Sie eine Instanz der Komponente Title auf der Seite erstellen und konfigurieren: <content-path>/Prototype.html
Touch-optimierte Benutzeroberfläche
Klassische Benutzeroberfläche
Dann sehen wir die Struktur des Inhalts, der innerhalb des Repositorys erstellt wurde:
Sehen Sie sich besonders den tatsächlichen Text für eine Titel-Komponente an:
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.
Die definierten Eigenschaften sind von den einzelnen Definitionen abhängig. Zwar können sie komplexer als oben dargestellt sein, folgen aber dennoch denselben grundlegenden Prinzipien.
Komponenten in AEM unterliegen drei verschiedenen Hierarchien:
Ressourcentyp-Hierarchie
Dies wird zum Erweitern von Komponenten mithilfe der Eigenschaft sling:resourceSuperType
verwendet. Dies aktiviert die Vererbung für die Komponente. Beispielsweise erbt eine Textkomponente verschiedene Attribute von der Standardkomponente.
Container-Hierarchie
Dies wird zum Füllen der Konfigurationseinstellungen für die untergeordnete Komponente verwendet und wird meist in einem Parsys-Szenario verwendet.
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 (im Zusammenhang mit der Bearbeitungsfunktion) in cq:editConfig
und cq:childEditConfig
werden übertragen.
Hierarchie einschließen
Dies wird zur Laufzeit durch die Sequenz von Includes auferlegt.
Diese Hierarchie wird vom Designer verwendet, der als Basis für die verschiedenen Designaspekte des Rendering fungiert; einschließlich Layoutangaben, CSS-Informationen, verfügbaren Komponenten in einem parsys usw.
In diesem Abschnitt wird beschrieben, wie Sie das Bearbeitungsverhalten einer Komponente konfigurieren. Hierzu zählen Attribute wie Aktionen, die für die Komponente verfügbar sind, Eigenschaften des Kontext-Editors und des Listeners in Zusammenhang mit Ereignissen bei der Komponente.
Die Konfiguration gilt dabei für die Touch-optimierte wie die klassische Benutzeroberfläche, wenn auch mit gewissen Unterschieden.
Um das Bearbeitungsverhalten einer Komponente zu konfigurieren, fügen Sie einen cq:editConfig
-Knoten des Typs cq:EditConfig
unter dem Komponentenknoten (des Typs cq:Component
) hinzu sowie spezifische Eigenschaften und untergeordnete Knoten. Die folgenden Funktionen und untergeordneten Knoten sind verfügbar:
cq:editConfig
Knoteneigenschaften:
cq:actions
( String array
) definiert die Aktionen, die für die Komponente ausgeführt werden können.
cq:layout
( String
) : definiert, wie die Komponente in der klassischen Benutzeroberfläche bearbeitet wird.
cq:dialogMode
( String
) legt fest, wie das Komponentendialogfeld in der klassischen Benutzeroberfläche geöffnet wird
cq:emptyText
( String
) definiert Text, der angezeigt wird, wenn kein sichtbarer Inhalt vorhanden ist.
cq:inherit
( Boolean
) definiert, ob fehlende Werte von der Komponente geerbt werden, von der sie übernommen wird.
dialogLayout
(String): legt fest, wie das Dialogfeld geöffnet werden soll
cq:editConfig
untergeordnete Knoten:
cq:dropTargets
(Knotentyp nt:unstructured
): definiert eine Liste von Dropdown-Zielgruppen, die ein Ablegen aus einem Asset der Inhaltssuche akzeptieren können
cq:actionConfigs
(Knotentyp nt:unstructured
): definiert eine Liste neuer Aktionen, die an die Liste "cq:actions"angehängt werden.
cq:formParameters
(Knotentyp nt:unstructured
): definiert zusätzliche Parameter, die dem Dialogfeld hinzugefügt werden.
cq:inplaceEditing
(Knotentyp cq:InplaceEditingConfig
): definiert eine ersetzende Bearbeitungskonfiguration für die Komponente.
cq:listeners
(Knotentyp cq:EditListenersConfig
): definiert, was vor oder nach einer Aktion für die Komponente geschieht.
Auf dieser Seite wird ein Knoten (Eigenschaften und untergeordnete Knoten) als XML dargestellt, wie im folgenden Beispiel gezeigt.
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit]"
cq:dialogMode="floating"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig">
<cq:listeners
jcr:primaryType="cq:EditListenersConfig"
afteredit="REFRESH_PAGE"/>
</jcr:root>
Es gibt zahlreiche vorhandene Konfigurationen im Repository. Sie können einfach nach bestimmten Eigenschaften oder untergeordneten Knoten suchen:
Um nach einer Eigenschaft des Knotens cq:editConfig
zu suchen, z. cq:actions
können Sie das Tool Abfrage in CRXDE Lite verwenden und mit der folgenden XPath-Abfrage-Zeichenfolge suchen:
/element(cq:editConfig, cq:EditConfig)[@cq:actions]
Um nach einem untergeordneten Knoten von cq:editConfig
zu suchen, können Sie z. B. nach cq:dropTargets
suchen, der vom Typ cq:DropTargetConfig
ist; Sie können das Tool Abfrage in CRXDE Lite verwenden und mit der folgenden XPath-Abfrage-Zeichenfolge suchen:
/element(cq:dropTargets, cq:DropTargetConfig)
Komponenten müssen immer HTML-Inhalte wiedergeben, die für den Autor sichtbar sind, auch wenn die Komponente keinen Inhalt hat. Andernfalls könnte es visuell aus der Benutzeroberfläche des Editors verschwinden, sodass es technisch vorhanden, aber auf der Seite und im Editor unsichtbar ist. In einem solchen Fall sind die Autoren nicht in der Lage, die leere Komponente auszuwählen und mit ihr zu interagieren.
Aus diesem Grund sollten Komponenten einen Platzhalter wiedergeben, solange sie keine sichtbare Ausgabe wiedergeben, wenn die Seite im Seiteneditor wiedergegeben wird (wenn der WCM-Modus edit
oder preview
ist).
Das typische HTML-Markup für einen Platzhalter ist Folgendes:
<div class="cq-placeholder" data-emptytext="Component Name"></div>
Das typische HTML-Skript, das den obigen Platzhalter-HTML-Code wiedergibt, lautet wie folgt:
<div class="cq-placeholder" data-emptytext="${component.properties.jcr:title}"
data-sly-test="${(wcmmode.edit || wcmmode.preview) && isEmpty}"></div>
Im vorherigen Beispiel ist isEmpty
eine Variable, die nur dann wahr ist, wenn die Komponente keinen Inhalt hat und für den Autor unsichtbar ist.
Um Wiederholungen zu vermeiden, empfiehlt Adobe, dass Komponentenimplementierer für diese Platzhalter eine HTML-Vorlage verwenden, wie die von den Hauptkomponenten bereitgestellten.
Die Verwendung der Vorlage im vorherigen Link erfolgt dann mit der folgenden HTML-Zeile:
<sly data-sly-use.template="core/wcm/components/commons/v1/templates.html"
data-sly-call="${template.placeholder @ isEmpty=!model.text}"></sly>
Im vorherigen Beispiel ist model.text
die Variable, die nur dann wahr ist, wenn der Inhalt Inhalte enthält und sichtbar ist.
Ein Beispiel für die Verwendung dieser Vorlage ist in den Hauptkomponenten, wie in der Titelkomponente zu finden.
Die cq:actions
-Eigenschaft ( String array
) definiert eine oder mehrere Aktionen, die für die Komponente ausgeführt werden können. Folgende Werte stehen für die Konfiguration zur Verfügung:
Eigenschaftswert | Beschreibung |
text:<some text> |
Zeigt den statischen Textwert <beliebiger Text> Nur in der klassischen Benutzeroberfläche sichtbar an. Die Touch-optimierte Benutzeroberfläche zeigt keine Aktionen in einem Kontextmenü an; daher trifft dieser Eigenschaftswert für sie nicht zu. |
- | Fügt einen Platzhalter hinzu. Nur in klassischer Benutzeroberfläche sichtbar. Die Touch-optimierte Benutzeroberfläche zeigt keine Aktionen in einem Kontextmenü an; daher trifft dieser Eigenschaftswert für sie nicht zu. |
edit |
Fügt eine Schaltfläche zum Bearbeiten der Komponente hinzu. |
editannotate |
Fügt eine Schaltfläche hinzu, um die Komponente zu bearbeiten und Anmerkungen zuzulassen. |
delete |
Fügt eine Schaltfläche zum Löschen der Komponente hinzu |
insert |
Fügt eine Schaltfläche hinzu, um eine neue Komponente vor der aktuellen Komponente einzufügen |
copymove |
Fügt eine Schaltfläche zum Kopieren und Ausschneiden der Komponente hinzu. |
Die folgende Konfiguration fügt eine Bearbeitungsschaltfläche, einen Abstand, eine Lösch- und eine Einfügungsschaltfläche zu der Bearbeitungsleiste der Komponente hinzu:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit,-,delete,insert]"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig"/>
Die folgende Konfiguration fügt den Text „Inherited Configurations from Base Framework“ (Vom Basis-Framework geerbte Konfigurationen) zur Bearbeitungsleiste der Komponente hinzu:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[text:Inherited Configurations from Base Framework]"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig"/>
Die cq:layout
-Eigenschaft ( String
) definiert, wie die Komponente in der klassischen Benutzeroberfläche bearbeitet werden kann. Die folgenden Werte sind verfügbar:
Eigenschaftswert | Beschreibung |
rollover |
Standardwert. Die Komponentenausgabe ist "on mouse over" über Klicks und/oder Kontextmenü zugänglich. Für erweiterte Verwendungen beachten Sie, dass das entsprechende clientseitige Objekt: CQ.wcm.EditRollover . |
editbar |
Auf die Komponentenausgabe kann über eine Symbolleiste zugegriffen werden. Für erweiterte Verwendungen beachten Sie, dass das entsprechende clientseitige Objekt: CQ.wcm.EditBar . |
auto |
Die Auswahl bleibt dem clientseitigen Code überlassen. |
Die Konzepte von rollover und editbar können in der Touch-optimierten Benutzeroberfläche nicht angewendet werden.
Die folgenden Konfigurationen fügen eine Bearbeitungsschaltfläche zur Bearbeitungsleiste der Komponente hinzu:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit]"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig">
</jcr:root>
Sie können die Komponente mit einem Dialogfeld „Bearbeiten“ verknüpfen. Die cq:dialogMode
-Eigenschaft ( String
) definiert, wie das Komponentendialogfeld in der klassischen Benutzeroberfläche geöffnet wird. Die folgenden Werte sind verfügbar:
Eigenschaftswert | Beschreibung |
floating |
Das Dialogfeld ist schwebend. |
inline |
(Standardwert). Das Dialogfeld wird über der Komponente verankert. |
auto |
Wenn die Komponentenbreite kleiner als der clientseitige CQ.themes.wcm.EditBase.INLINE_MINIMUM_WIDTH -Wert ist, ist das Dialogfeld schwebend, andernfalls ist es inline. |
In der Touch-optimierten Benutzeroberfläche sind die Dialogfelder im Desktopmodus immer unverankert und werden im mobilen Modus immer im Vollbild geöffnet.
Die folgende Konfiguration definiert eine Bearbeitungsleiste mit einer Bearbeitungsschaltfläche und einem unverankerten Dialogfeld:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit]"
cq:dialogMode="floating"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig">
</jcr:root>
Die cq:emptyText
-Eigenschaft ( String
) definiert den Text, der angezeigt wird, wenn kein sichtbarer Inhalt vorhanden ist. Standardwert ist: Drag components or assets here
.
Die cq:inherit
-Eigenschaft ( boolean
) definiert, ob fehlende Werte von der Komponente übernommen werden, von der sie übernommen wird. Standardwert ist false
.
Die Eigenschaft dialogLayout
legt fest, wie ein Dialogfeld standardmäßig geöffnet werden soll.
fullscreen
öffnet das Dialogfeld im Vollbildmodus.Der Knoten cq:dropTargets
(Knotentyp nt:unstructured
) definiert eine Liste von Dropdown-Zielgruppen, die ein Ablegen eines aus der Inhaltssuche gezogenen Assets akzeptieren können. Er dient als Sammlung von Knoten des Typs cq:DropTargetConfig
.
Mehrere Ablageziele sind nur in der klassischen Benutzeroberfläche verfügbar.
In der Touch-optimierten Benutzeroberfläche wird nur das erste Ziel verwendet.
Jeder untergeordnete Knoten des Typs cq:DropTargetConfig
definiert eine Drop-Zielgruppe in der Komponente. Der Knotenname ist wichtig, da er im JSP wie folgt verwendet werden muss, um den CSS-Klassennamen zu erzeugen, der dem DOM-Element zugewiesen wird, das das effektive Ablageziel ist:
<drop target css class> = <drag and drop prefix> +
<node name of the drop target in the edit configuration>
Das <drag and drop prefix>
wird durch die Java-Eigenschaft definiert:
com.day.cq.wcm.api.components.DropTarget.CSS_CLASS_PREFIX
.
Beispielsweise wird der Klassenname im JSP der Download-Komponente wie folgt definiert
( /libs/foundation/components/download/download.jsp
), wobei file
der Knotenname der Drop-Zielgruppe in der Bearbeitungskonfiguration der Download-Komponente ist:
String ddClassName = DropTarget.CSS_CLASS_PREFIX + "file";
Der Knoten des Typs cq:DropTargetConfig
muss die folgenden Eigenschaften aufweisen:
Eigenschaftsname | Eigenschaftswert |
accept |
Regex auf den Asset-Mime-Typ angewendet, um zu überprüfen, ob das Ablegen zulässig ist. |
groups |
Array von Dropdown-Zielpopulationen. Jede Gruppe muss mit dem Gruppentyp übereinstimmen, der in der Content Finder-Erweiterung definiert wurde und der bei den Assets angehängt ist. |
propertyName |
Name der Eigenschaft, die nach einem gültigen Ablegen aktualisiert wird. |
Die folgende Konfiguration stammt aus der Download-Komponente. Sie ermöglicht es, dass jedes Asset (der MIME-Typ kann jeder beliebige String sein) aus der Gruppe media
vom Content Finder in der Komponente abgelegt werden kann. Nach der Ablage wird die Komponenteneigenschaft fileReference
aktualisiert:
<cq:dropTargets jcr:primaryType="nt:unstructured">
<file
jcr:primaryType="cq:DropTargetConfig"
accept="[.*]"
groups="[media]"
propertyName="./fileReference"/>
</cq:dropTargets>
Der Knoten cq:actionConfigs
(Knotentyp nt:unstructured
) definiert eine Liste neuer Aktionen, die an die Liste angehängt werden, die durch die Eigenschaft cq:actions
definiert wird. Jeder untergeordnete Knoten von cq:actionConfigs
definiert eine Aktion, indem er ein Widget definiert.
Die folgende Beispielkonfiguration definiert eine neue Schaltfläche (mit einem Trennzeichen für die klassische Benutzeroberfläche):
ein Trennzeichen, definiert durch den xtype tbseparator
;
eine Schaltfläche mit dem Namen Kommentare verwalten, über die die Handler-Funktion CQ_collab_forum_openCollabAdmin()
ausgeführt wird.
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
cq:actions="[EDIT,COPYMOVE,DELETE,INSERT]"
jcr:primaryType="cq:EditConfig">
<cq:actionConfigs jcr:primaryType="nt:unstructured">
<separator0
jcr:primaryType="nt:unstructured"
xtype="tbseparator"/>
<manage
jcr:primaryType="nt:unstructured"
handler="function(){CQ_collab_forum_openCollabAdmin();}"
text="Manage comments"/>
</cq:actionConfigs>
</jcr:root>
Ein Beispiel für die Touch-optimierte Benutzeroberfläche finden Sie unter Hinzufügen neuer Aktionen zu Komponenten-Symbolleisten.
Der Knoten cq:formParameters
(Knotentyp nt:unstructured
) definiert zusätzliche Parameter, die dem Dialogfeld hinzugefügt werden. Jede Eigenschaft wird einem Formularparameter zugeordnet.
Die folgende Konfiguration fügt einen Parameter namens name
mit dem Wert photos/primary
zum Dialogfeldformular hinzu:
<cq:formParameters
jcr:primaryType="nt:unstructured"
name="photos/primary"/>
Der Knoten cq:inplaceEditing
(Knotentyp cq:InplaceEditingConfig
) definiert eine ersetzende Bearbeitungskonfiguration für die Komponente. Er kann die folgenden Eigenschaften aufweisen:
Eigenschaftsname | Eigenschaftswert |
active |
(boolean ) True, um die Bearbeitung der Komponente in Inplace zu aktivieren. |
configPath |
(String ) Pfad der Editorkonfiguration. Die Konfiguration kann durch einen Konfigurationsknoten festgelegt werden. |
editorType |
(
|
Die folgende Konfiguration aktiviert die Kontextbearbeitung der Komponente und legt plaintext
als Editor-Typ fest:
<cq:inplaceEditing
jcr:primaryType="cq:InplaceEditingConfig"
active="{Boolean}true"
editorType="plaintext"/>
Der Knoten cq:listeners
(Knotentyp cq:EditListenersConfig
) definiert, was vor oder nach einer Aktion für die Komponente geschieht. In der folgenden Tabelle sind die möglichen Eigenschaften aufgeführt.
Eigenschaftsname | Eigenschaftswert |
Standardwert (Nur klassische Benutzeroberfläche) |
beforedelete |
Der Handler wird ausgelöst, bevor die Komponente entfernt wird. |
|
beforeedit |
Der Handler wird ausgelöst, bevor die Komponente bearbeitet wird. | |
beforecopy |
Der Handler wird ausgelöst, bevor die Komponente kopiert wird. | |
beforemove |
Der Handler wird ausgelöst, bevor die Komponente verschoben wird. | |
beforeinsert |
Der Handler wird ausgelöst, bevor die Komponente eingefügt wird. Nur für die touchfähige Benutzeroberfläche verfügbar. |
|
beforechildinsert |
Der Handler wird ausgelöst, bevor die Komponente in eine andere Komponente eingefügt wird (nur Container). | |
afterdelete |
Der Handler wird ausgelöst, nachdem die Komponente entfernt wurde. | REFRESH_SELF |
afteredit |
Der Handler wird ausgelöst, nachdem die Komponente bearbeitet wurde. | REFRESH_SELF |
aftercopy |
Der Handler wird ausgelöst, nachdem die Komponente kopiert wurde. | REFRESH_SELF |
afterinsert |
Der Handler wird ausgelöst, nachdem die Komponente eingefügt wurde. | REFRESH_INSERTED |
aftermove |
Der Handler wird ausgelöst, nachdem die Komponente verschoben wurde. | REFRESH_SELFMOVED |
afterchildinsert |
Der Handler wird ausgelöst, nachdem die Komponente in eine andere Komponente eingefügt wurde (nur Container). |
Die Handler REFRESH_INSERTED
und REFRESH_SELFMOVED
stehen nur in der klassischen Benutzeroberfläche zur Verfügung.
Standardwerte für die Listener werden nur in der klassischen Benutzeroberfläche festgelegt.
Bei verschachtelten Komponenten gibt es bestimmte Einschränkungen bezüglich der Aktionen, die als Eigenschaften auf dem Knoten cq:listeners
definiert werden:
REFRESH_PAGE
sein: >aftermove
aftercopy
Der Ereignis-Handler kann mit einer angepassten Implementierung implementiert werden. Beispiel (hier ist project.customerAction
eine statische Methode):
afteredit = "project.customerAction"
Das folgende Beispiel entspricht der REFRESH_INSERTED
-Konfiguration:
afterinsert="function(path, definition) { this.refreshCreated(path, definition); }"
Für die klassische Benutzeroberfläche, um zu sehen, welche Parameter in den Handlern verwendet werden können, lesen Sie den Abschnitt before<action>
und after<action>
Ereignis in der Widget-Dokumentation CQ.wcm.EditBar
und CQ.wcm.EditRollover
.
Mit der folgenden Konfiguration wird die Seite aktualisiert, nachdem die Komponente gelöscht, bearbeitet, eingefügt oder verschoben wurde:
<cq:listeners
jcr:primaryType="cq:EditListenersConfig"
afterdelete="REFRESH_PAGE"
afteredit="REFRESH_PAGE"
afterinsert="REFRESH_PAGE"
afterMove="REFRESH_PAGE"/>