Inhaltsmodellierung für WYSIWYG-Authoring-Projekte mit Edge Delivery Services content-modeling

Erfahren Sie, wie die Inhaltsmodellierung für WYSIWYG-Authoring-Projekte mit Edge Delivery Services funktioniert und wie Sie eigene Inhalte modellieren.

Voraussetzungen prerequisites

Projekte, die WYSIWYG-Authoring mit Edge Delivery Services verwenden, erben den Großteil der Mechanismen anderer Edge Delivery Services-Projekte, und zwar unabhängig von der Inhaltsquelle oder 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.

Das Modell dieser Komponenten ist Teil der Vorlage für das WYSIWYG-Authoring mit Edge Delivery Services.

Bausteine blocks

Blöcke werden verwendet, um vielfältigere Inhalte mit bestimmten Stilen und Funktionen zu erstellen. Im Gegensatz zu Standardinhalten erfordern Bausteine 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

Beim WYSIWYG-Authoring mit Edge Delivery Services muss der Inhalt der Bausteine explizit modelliert werden, damit der Autorin oder dem Autor die Benutzeroberfläche zur Inhaltserstellung zur Verfügung gestellt wird. 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:

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.

{
  "name": "Hero",
  "model": "hero",
  "image": "/content/dam/image.png",
  "imageAlt": "Helix - a shape like a corkscrew",
  "text": "<h1>Welcome to AEM</h1>"
}

<div class="hero">
  <div>
    <div>
      <picture>
        <img src="/content/dam/image.png" alt="Helix - a shape like a corkscrew">
      </picture>
    </div>
  </div>
  <div>
    <div>
      <h1>Welcome to AEM</h1>
    </div>
  </div>
</div>

+---------------------------------------------+
| Hero                                        |
+=============================================+
| ![Helix - a shape like a corkscrew][image0] |
+---------------------------------------------+
| # Welcome to AEM                            |
+---------------------------------------------+

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.

{
  "name": "Featured Articles",
  "model": "spreadsheet-input",
  "key-value": true,
  "source": "/content/site/articles.json",
  "keywords": ['Developer','Courses'],
  "limit": 4
}

<div class="featured-articles">
  <div>
    <div>source</div>
    <div><a href="/content/site/articles.json">/content/site/articles.json</a></div>
  </div>
  <div>
    <div>keywords</div>
    <div>Developer,Courses</div>
  <div>
  <div>
    <div>limit</div>
    <div>4</div>
  </div>
</div>

+-----------------------------------------------------------------------+
| Featured Articles                                                     |
+=======================================================================+
| source   | [/content/site/articles.json](/content/site/articles.json) |
+-----------------------------------------------------------------------+
| keywords | Developer,Courses                                          |
+-----------------------------------------------------------------------+
| limit    | 4                                                          |
+-----------------------------------------------------------------------+

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.

{
  "name": "Our Partners",
  "model": "text-only",
  "filter": "our-partners",
  "text": "<p>Our community of partners is ...</p>",
  "item_0": {
    "model": "linked-icon",
    "image": "/content/dam/partners/foo.png",
    "imageAlt": "Icon of Foo",
    "link": "https://foo.com/"
  },
  "item_1": {
    "model": "linked-icon"
    "image": "/content/dam/partners/bar.png",
    "imageAlt": "Icon of Bar",
    "link": "https://bar.com"
  }
}

<div class="our-partners">
  <div>
    <div>
        Our community of partners is ...
    </div>
  </div>
  <div>
    <div>
      <picture>
         <img src="/content/dam/partners/foo.png" alt="Icon of Foo">
      </picture>
    </div>
    <div>
      <a href="https://foo.com">https://foo.com</a>
    </div>
  </div>
  <div>
    <div>
      <picture>
         <img src="/content/dam/partners/bar.png" alt="Icon of Bar">
      </picture>
    </div>
    <div>
      <a href="https://bar.com">https://bar.com</a>
    </div>
  </div>
</div>

+------------------------------------------------------------ +
| Our Partners                                                |
+=============================================================+
| Our community of partners is ...                            |
+-------------------------------------------------------------+
| ![Icon of Foo][image0] | [https://foo.com](https://foo.com) |
+-------------------------------------------------------------+
| ![Icon of Bar][image1] | [https://bar.com](https://bar.com) |
+-------------------------------------------------------------+

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.

Beim WYSIWYG-Authoring mit Edge Delivery Services wirft dies die Frage auf, wie ein überzeugendes semantisches Inhaltsmodell bereitgestellt werden kann, wenn die Informationen mit aus mehreren Feldern bestehenden Formularen erstellt werden, anstatt semantisches Markup so wie Rich-Text kontextbezogen 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:

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

{
  "image": "/content/dam/red-car.png",
  "imageAlt: "A red card on a road"
}

<picture>
  <img src="/content/dam/red-car.png" alt="A red car on a road">
</picture>

![A red car on a road][image0]

Links und Schaltflächen links-buttons-collapse

{
  "link": "https://www.adobe.com",
  "linkTitle": "Navigate to adobe.com",
  "linkText": "adobe.com",
  "linkType": "primary"
}

<a href="https://www.adobe.com" title="Navigate to adobe.com">adobe.com</a>

<strong>
  <a href="https://www.adobe.com" title="Navigate to adobe.com">adobe.com</a>
</strong>

<em>
  <a href="https://www.adobe.com" title="Navigate to adobe.com">adobe.com</a>
</em>

[adobe.com](https://www.adobe.com "Navigate to adobe.com")
**[adobe.com](https://www.adobe.com "Navigate to adobe.com")**
_[adobe.com](https://www.adobe.com "Navigate to adobe.com")_

Überschriften headings-collapse

{
  "heading": "Getting started",
  "headingType": "h2"
}

<h2>Getting started</h2>

## Getting started

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.

{
  "name": "teaser",
  "model": "teaser",
  "image": "/content/dam/teaser-background.png",
  "imageAlt": "A group of people sitting on a stage",
  "teaserText_subtitle": "Adobe Experience Cloud"
  "teaserText_title": "Meet the Experts"
  "teaserText_titleType": "h2"
  "teaserText_description": "<p>Join us in this ask me everything session...</p>"
  "teaserText_cta1": "https://link.to/more-details",
  "teaserText_cta1Text": "More Details"
  "teaserText_cta2": "https://link.to/sign-up",
  "teaserText_cta2Text": "RSVP",
  "teaserText_cta2Type": "primary"
}

<div class="teaser">
  <div>
    <div>
      <picture>
        <img src="/content/dam/teaser-background.png" alt="A group of people sitting on a stage">
      </picture>
    </div>
  </div>
  <div>
    <div>
      <p>Adobe Experience Cloud</p>
      <h2>Meet the Experts</h2>
      <p>Join us in this ask me everything session ...</p>
      <p><a href="https://link.to/more-details">More Details</a></p>
      <p><strong><a href="https://link.to/sign-up">RSVP</a></strong></p>
    </div>
  </div>
</div>

+-------------------------------------------------+
| Teaser                                          |
+=================================================+
| ![A group of people sitting on a stage][image0] |
+-------------------------------------------------+
| Adobe Experience Cloud                          |
| ## Meet the Experts                             |
| Join us in this ask me everything session ...   |
| [More Details](https://link.to/more-details)    |
| [RSVP](https://link.to/sign-up)                 |
+-------------------------------------------------+

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 von Tabellendaten.

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:

Es ist auch möglich, ein Komponentenmodell für benutzerdefinierte Seitenmetadaten zu definieren, das der Autorin oder 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 Sie Bausteine für Ihre eigenen Edge Delivery Service-Projekte mit WYSIWYG-Authoring erstellen.

Im Dokument Erstellen von für den universellen Editor instrumentierten Bausteinen erfahren Sie, wie Sie Bausteine erstellen, die für die Verwendung mit dem universellen Editor in WYSIWYG-Authoring mit Edge Delivery Services-Projekten instrumentiert sind.

Wenn Sie bereits mit der Erstellung von Blöcken vertraut sind, lesen Sie bitte das Erste-Schritte-Handbuch für Entwickelnde zum WYSIWYG-Authoring mit Edge Delivery Services, um Ihnen den Start mit einer neuen Adobe Experience Manager-Site zu erleichtern, wobei Sie Edge Delivery Services und den universellen Editor für die Erstellung von Inhalten verwenden.