Inhaltsmodellierung für WYSIWYG Authoring mit Edge Delivery Services-Projekten content-modeling
Erfahren Sie, wie die Inhaltsmodellierung für WYSIWYG Authoring mit Edge Delivery Services-Projekten funktioniert und wie Sie Ihre eigenen Inhalte modellieren.
Voraussetzungen prerequisites
Projekte, die WYSIWYG Authoring mit Edge Delivery Services verwenden, erben den Großteil der Mechanismen anderer Edge Delivery Services-Projekte, unabhängig von der Inhaltsquelle oder der Authoring-Methode.
Bevor Sie mit der Modellierung von Inhalten für Ihr Projekt beginnen, lesen Sie zunächst Folgendes:
Es ist wichtig, diese Konzepte zu verstehen, um ein überzeugendes Inhaltsmodell zu entwickeln, das unabhängig von Inhaltsquellen funktioniert. Dieses Dokument enthält Details zu den Mechanismen, die speziell für das WYSIWYG-Authoring implementiert wurden.
Standardinhalt default-content
Standardinhalt ist Inhalt, den eine Autorin oder ein Autor intuitiv auf eine Seite platzieren würde, ohne zusätzliche Semantik hinzuzufügen. Dazu gehören Text, Überschriften, Links und Bilder. Solche Inhalte sind in ihrer Funktion und ihrem Zweck selbsterklärend.
In AEM werden diese Inhalte als Komponenten mit sehr einfachen, vordefinierten Modellen implementiert, die alles enthalten, was in Markdown und HTML serialisiert werden kann.
- Text: Rich-Text (einschließlich Listenelementen und fett oder kursiv formatiertem Text)
- Titel: Text, Typ (h1-h6)
- Bild: Quelle, Beschreibung
- Schaltfläche: Text, Titel, URL, Typ (Standard, primär, sekundär)
Das Modell dieser Komponenten ist Teil der Bausteinvorlage für WYSIWYG-Authoring mit Edge Delivery Services.
Blöcke blocks
Blöcke werden verwendet, um vielfältigere Inhalte mit bestimmten Stilen und Funktionen zu erstellen. Im Gegensatz zu Standardinhalten erfordern Blöcke keine zusätzliche Semantik.
Blöcke sind im Wesentlichen Inhaltselemente, die von JavaScript dekoriert und mit einem Stylesheet formatiert werden.
Definition des Blockmodells model-definition
Bei der Verwendung von WYSIWYG-Authoring mit Edge Delivery Services muss der Inhalt von Bausteinen explizit modelliert werden, um dem Autor die Benutzeroberfläche zum Erstellen von Inhalten bereitzustellen. Grundsätzlich müssen Sie ein Modell erstellen, damit die Authoring-Benutzeroberfläche weiß, welche Optionen der Autorin oder dem Autor basierend auf dem Block präsentiert werden sollen.
Die Datei component-models.json
definiert das Blockmodell. Die im Komponentenmodell definierten Felder werden als Eigenschaften in AEM beibehalten und als Zellen in der Tabelle gerendert, aus der sich ein Block zusammensetzt.
{
"id": "hero",
"fields": [
{
"component": "reference",
"valueType": "string",
"name": "image",
"label": "Image",
"multi": false
},
{
"component": "text-input",
"valueType": "string",
"name": "imageAlt",
"label": "Alt",
"value": ""
},
{
"component": "text-area",
"name": "text",
"value": "",
"label": "Text",
"valueType": "string"
}
]
}
Nicht jeder Block muss über ein Modell verfügen. Einige Blöcke sind einfach Container für eine Liste von untergeordneten Elementen. Dabei hat jedes untergeordnete Element ein eigenes Modell.
Außerdem müssen Sie definieren, welche Blöcke vorhanden sind und mit dem universellen Editor zu einer Seite hinzugefügt werden können. Die Datei component-definitions.json
listet die Komponenten so auf, wie sie vom universellen Editor zur Verfügung gestellt werden.
{
"title": "Hero",
"id": "hero",
"plugins": {
"xwalk": {
"page": {
"resourceType": "core/franklin/components/block/v1/block",
"template": {
"name": "Hero",
"model": "hero"
}
}
}
}
}
Es ist möglich, ein Modell für eine Vielzahl von Blöcken zu verwenden. Einige Blöcke können beispielsweise ein gemeinsames Modell haben, das einen Text und ein Bild definiert.
Für jeden Block gilt Folgendes:
- Die Entwicklerin oder der Entwickler muss den Ressourcentyp
core/franklin/components/block/v1/block
verwenden, die generische Implementierung der Blocklogik in AEM. - Die Entwicklerin oder der Entwickler muss den Blocknamen definieren, der in der Tabellenüberschrift des Blocks gerendert wird.
- Anhand des Blocknamens werden der richtige Stil und das richtige Skript zum Dekorieren des Blocks abgerufen.
- Die Entwicklerin oder der Entwickler kann eine Modell-ID definieren.
- Die Modell-ID ist ein Verweis auf das Modell der Komponente, das die Felder definiert, die dem Autor im Eigenschaftenbereich zur Verfügung stehen.
- Die Entwicklerin oder der Entwickler kann eine Filter-ID definieren.
- Die Filter-ID ist ein Verweis auf den Filter der Komponente, der es ermöglicht, das Authoring-Verhalten zu ändern, z. B. indem begrenzt wird, welche untergeordneten Elemente zum Block oder Abschnitt hinzugefügt werden können oder welche RTE-Funktionen aktiviert sind.
Alle diese Informationen werden in AEM gespeichert, wenn ein Block zu einer Seite hinzugefügt wird. Wenn der Ressourcentyp oder der Blockname fehlt, wird der Block nicht auf der Seite gerendert.
Blockstruktur block-structure
Die Eigenschaften von Blöcken sind in den Komponentenmodellen definiert und werden als solche in AEM beibehalten. Eigenschaften werden als Zellen in der tabellenähnlichen Struktur des Blocks gerendert.
Einfache Blöcke simple
In der einfachsten Form rendert ein Block jede Eigenschaft in einer Zeile/Spalte in der Reihenfolge, in der die Eigenschaften im Modell definiert sind.
Im folgenden Beispiel wird zuerst das Bild im Modell und dann der Text definiert. An diese Reihenfolge wird sich auch beim Rendern gehalten.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Sie stellen möglicherweise fest, dass einige Werttypen die Ableitung von Semantik im Markup zulassen und Eigenschaften in einzelnen Zellen kombiniert werden. Dieses Verhalten wird unter Typableitung beschrieben.
Schlüssel-Wert-Block key-value
In vielen Fällen wird empfohlen, das gerenderte semantische Markup zu dekorieren, CSS-Klassennamen hinzuzufügen, neue Knoten hinzuzufügen oder sie im DOM zu verschieben und Stile anzuwenden.
In anderen Fällen wird der Block jedoch als eine Schlüssel-Wert-Paar-ähnliche Konfiguration gelesen.
Ein Beispiel hierfür sind die Abschnittsmetadaten. In diesem Anwendungsfall kann der Block so konfiguriert werden, dass er als Schlüssel-Wert-Paar-Tabelle gerendert wird. Weitere Informationen finden Sie unter Abschnitte und Abschnittsmetadaten.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Container-Blöcke container
Beide vorherigen Strukturen haben eine einzige Dimension: die Liste der Eigenschaften. Container-Blöcke ermöglichen das Hinzufügen von untergeordneten Elementen (normalerweise vom gleichen Typ oder Modell) und sind daher zweidimensional. Diese Blöcke unterstützen weiterhin ihre eigenen Eigenschaften, die zuerst als Zeilen mit einer Spalte gerendert werden. Sie ermöglichen jedoch auch das Hinzufügen von untergeordneten Elementen, für die jedes Element als Zeile und jede Eigenschaft als Spalte in dieser Zeile gerendert wird.
Im folgenden Beispiel akzeptiert ein Block eine Liste verknüpfter Symbole als untergeordnete Elemente. Dabei verfügt jedes verknüpfte Symbol über ein Bild und einen Link. Achten Sie auf die in den Daten des Blocks festgelegte Filter-ID. Darüber wird auf die Filterkonfiguration verwiesen.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Erstellen semantischer Inhaltsmodelle für Blöcke creating-content-models
Auf Grundlage der erläuterten Mechanismen der Blockstruktur ist es nun möglich, ein Inhaltsmodell zu erstellen, das die in AEM gespeicherten Inhalte der Bereitstellungsebene eins zu eins zuordnet.
In der Frühphase jedes Projekts muss ein Inhaltsmodell für jeden Block sorgfältig überdacht werden. Es muss unabhängig von der Inhaltsquelle und dem Authoring-Erlebnis sein. Nur so können sie von Autorinnen und Autoren gewechselt oder kombiniert werden, bei Wiederverwendung von Blockimplementierungen und Stilen. Weitere Informationen und allgemeine Leitlinien finden Sie unter Davids Modell (Take 2). Genauer gesagt, enthält die Blocksammlung einen umfangreichen Satz an Inhaltsmodellen für spezifische Anwendungsfälle gängiger Benutzeroberflächenmuster.
Für WYSIWYG-Authoring mit Edge Delivery Services stellt sich die Frage, wie ein überzeugendes semantisches Inhaltsmodell bereitgestellt werden kann, wenn die Informationen mit Formularen erstellt werden, die aus mehreren Feldern bestehen, anstatt das semantische Markup im Kontext wie Rich Text zu bearbeiten.
Zur Lösung dieses Problems gibt es drei Methoden, die die Erstellung eines überzeugenden Inhaltsmodells erleichtern:
Typableitung type-inference
Für einige Werte kann die semantische Bedeutung aus den Werten selbst abgeleitet werden. Zu solchen Werten zählen:
- Bilder: Wenn eine Referenz auf eine Ressource in AEM ein Asset mit einem MIME-Typ ist, der mit
image/
beginnt, wird die Referenz als<picture><img src="${reference}"></picture>
gerendert. - Links: Wenn eine Referenz in AEM vorhanden ist, die kein Bild ist, oder wenn der Wert mit
https?://
oder#
beginnt, wird die Referenz als<a href="${reference}">${reference}</a>
gerendert. - Rich-Text: Wenn ein abgeschnittener Wert mit einem Absatz beginnt (
p
,ul
,ol
,h1
-h6
usw.), wird der Wert als Rich-Text gerendert. - Klassennamen: Die
classes
-Eigenschaft wird als Blockoptionen behandelt und in der Tabellenkopfzeile für einfache Blöcke bzw. als Werteliste für Elemente in einem Container-Block gerendert. Sie ist nützlich, wenn Sie einen Block anders gestalten, aber keinen völlig neuen Block erstellen möchten. - Wertelisten: Wenn es sich bei einem Wert um eine Eigenschaft mit mehreren Werten handelt und der erste Wert keiner der vorherigen ist, werden alle Werte als kommagetrennte Liste verkettet.
Alles andere wird als einfacher Text gerendert.
Ausblendung von Feldern field-collapse
Beim Ausblenden von Feldern werden mehrere Feldwerte basierend auf einer Namenskonvention mithilfe der Suffixe Title
, Type
, MimeType
, Alt
und Text
(unter Berücksichtigung der Groß- und Kleinschreibung) zu einem einzigen semantischen Element zusammengefasst. Jede Eigenschaft, die mit einem dieser Suffixe endet, wird nicht als Wert, sondern als Attribut einer anderen Eigenschaft betrachtet.
Bilder image-collapse
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Links und Schaltflächen links-buttons-collapse
code language-json |
---|
|
Kein linkType
oder linkType=default
code language-html |
---|
|
linkType=primary
code language-html |
---|
|
linkType=secondary
code language-html |
---|
|
code language-text |
---|
|
Überschriften headings-collapse
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Elementgruppierung element-grouping
Bei der Ausblendung von Feldern werden mehrere Eigenschaften zu einem einzigen semantischen Element kombiniert, wohingegen es bei der Elementgruppierung darum geht, mehrere semantische Elemente zu einer einzigen Zelle zu verketten. Dies ist besonders hilfreich in Anwendungsfällen, in denen die Autorin oder der Autor in Bezug auf Art und Anzahl der Elemente, die sie bzw. er erstellen kann, eingeschränkt werden soll.
Beispielsweise kann eine Teaser-Komponente der Autorin oder dem Autor erlauben, nur einen Untertitel, einen Titel und eine einzelne Absatzbeschreibung sowie maximal zwei Aktionsaufruf-Schaltflächen zu erstellen. Wenn Sie diese Elemente gruppieren, erhalten Sie ein semantisches Markup, das ohne weitere Maßnahmen formatiert werden kann.
Die Elementgruppierung verwendet eine Namenskonvention, bei der der Gruppenname durch einen Unterstrich von jeder Eigenschaft in der Gruppe getrennt wird. Die Ausblendung der Felder für die Eigenschaften in einer Gruppe funktioniert wie zuvor beschrieben.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Abschnitte und Abschnittsmetadaten sections-metadata
Entwickelnde können verschiedene Abschnitte auf die gleiche Weise definieren, auf die sie auch mehrere Blöcke definieren und modellieren.
Das Inhaltsmodell von Edge Delivery Services lässt absichtlich nur eine einzige Verschachtelungsebene zu, d. h. jeder Standard-Content oder -block, der in einem Abschnitt enthalten ist. Um komplexere visuelle Komponenten zu erhalten, die andere Komponenten enthalten können, müssen diese daher als Abschnitte modelliert und mithilfe der Client-seitigen automatischen Blockerstellung kombiniert werden. Typische Beispiele hierfür sind Registerkarten und ausblendbare Abschnitte wie Akkordeons.
Ein Abschnitt kann auf die gleiche Weise wie ein Block definiert werden, jedoch mit dem Ressourcentyp core/franklin/components/section/v1/section
. Abschnitte können einen Namen und eine Filter-ID haben, die nur vom universellen Editor verwendet wird, sowie eine Modell-ID, die zum Rendern der Abschnittsmetadaten verwendet wird. Das Modell ist auf diese Weise das Modell des Bereichsmetadatenblocks, der automatisch als Schlüssel-Wert-Block an einen Abschnitt angehängt wird, wenn dieser nicht leer ist.
Die Modell-ID und Filter-ID des Standardabschnitts ist section
. Sie kann verwendet werden, um das Verhalten des Standardabschnitts zu ändern. Im folgenden Beispiel werden dem Abschnittsmetadatenmodell einige Stile und ein Hintergrundbild hinzugefügt.
{
"id": "section",
"fields": [
{
"component": "multiselect",
"name": "style",
"value": "",
"label": "Style",
"valueType": "string",
"options": [
{
"name": "Fade in Background",
"value": "fade-in"
},
{
"name": "Highlight",
"value": "highlight"
}
]
},
{
"component": "reference",
"valueType": "string",
"name": "background",
"label": "Image",
"multi": false
}
]
}
Im folgenden Beispiel wird ein Registerkartenabschnitt definiert, der zum Erstellen eines Registerkartenblocks verwendet werden kann, indem aufeinander folgende Abschnitte mit einem Registerkartentitel-Datenattribut während der automatischen Blockerstellung in einen Registerkartenblock kombiniert werden.
{
"title": "Tab",
"id": "tab",
"plugins": {
"xwalk": {
"page": {
"resourceType": "core/franklin/components/section/v1/section",
"template": {
"name": "Tab",
"model": "tab",
"filter": "section"
}
}
}
}
}
Seitenmetadaten page-metadata
Dokumente können eine Seite Metadatenblock enthalten, mit der definiert wird, welche <meta>
-Elemente im <head>
einer Seite gerendert werden. Die Seiteneigenschaften von Seiten in AEM as a Cloud Service sind denen zugeordnet, die standardmäßig für Edge Delivery Services verfügbar sind, z. B. title
, description
, keywords
.
Bevor Sie weitere Informationen zum Definieren Ihrer eigenen Metadaten erhalten, lesen Sie zunächst die folgenden Dokumente, um das Konzept der Seitenmetadaten zu verstehen.
Es ist auch möglich, zusätzliche Seitenmetadaten auf zwei Arten zu definieren.
Metadaten-Tabellen metadata-spreadsheets
Es ist möglich, Metadaten in AEM as a Cloud Service anhand von Pfaden oder Pfadmustern auf tabellenähnliche Weise zu definieren. Es gibt eine Authoring-Benutzeroberfläche für tabellenähnliche Daten, die Excel- oder Google-Tabellen ähneln.
Weitere Informationen finden Sie im Dokument Verwenden von Tabellen zur Verwaltung tabellarischer Daten .
Seiteneigenschaften page-properties
Viele der in AEM verfügbaren Standardseiteneigenschaften werden den entsprechenden Seitenmetadaten in einem Dokument zugeordnet. Das umfasst beispielsweise title
, description
, robots
, canonical url
oder keywords
. Einige AEM-spezifische Eigenschaften sind ebenfalls verfügbar:
cq:lastModified
alsmodified-time
im ISO8601-Format- Zeitpunkt der letzten Veröffentlichung des Dokuments als
published-time
im ISO8601-Format cq:tags
alscq-tags
als kommagetrennte Liste der Tag-IDs.
Es ist auch möglich, ein Komponentenmodell für benutzerdefinierte Seitenmetadaten zu definieren, das dem Autor im universellen Editor zur Verfügung gestellt wird.
Erstellen Sie dazu ein Komponentenmodell mit der ID page-metadata
.
{
"id": "page-metadata",
"fields": [
{
"component": "text",
"name": "theme",
"label": "Theme"
}
]
}
Nächste Schritte next-steps
Nachdem Sie nun wissen, wie Sie Inhalte modellieren können, können Sie mit dem WYSIWYG-Authoring-Projekt Bausteine für Ihre eigenen Edge Delivery Services erstellen.
Informationen zum Erstellen von für die Verwendung mit dem universellen Editor instrumentierten Bausteinen🔗 finden Sie im Dokument Erstellen von Bausteinen, die für die Verwendung mit dem universellen Editor bei der WYSIWYG-Bearbeitung mit Edge Delivery Services-Projekten instrumentiert wurden.
Wenn Sie bereits mit dem Erstellen von Bausteinen vertraut sind, lesen Sie das Dokument Entwicklerhandbuch für WYSIWYG-Authoring mit Edge Delivery Services , um Sie mit einer neuen Adobe Experience Manager-Site vertraut zu machen, die Edge Delivery Services und den universellen Editor für die Inhaltserstellung verwendet.