Modellazione dei contenuti per l’authoring WYSIWYG con progetti Edge Delivery Services content-modeling

Scopri come funziona la modellazione dei contenuti per l’authoring WYSIWYG con progetti di Edge Delivery Services e come modellare i tuoi contenuti.

Prerequisiti prerequisites

I progetti che utilizzano l'authoring WYSIWYG con Edge Delivery Services ereditano la maggior parte dei meccanismi di qualsiasi altro progetto di Edge Delivery Services, indipendentemente dall'origine di contenuto o dal metodo di authoring .

Prima di iniziare a modellare il contenuto per il progetto, assicurati di aver letto la seguente documentazione.

È essenziale comprendere tali concetti per trovare un modello di contenuto convincente che funzioni in modo indipendente dall’origine dei contenuti. Questo documento fornisce dettagli sulla meccanica implementata specificamente per l’authoring WYSIWYG.

Contenuto predefinito default-content

Il contenuto predefinito sono gli elementi che un autore può inserire in modo intuitivo in una pagina senza aggiungere alcuna ulteriore semantica. Sono inclusi testo, intestazioni, collegamenti e immagini. La funzione e lo scopo di tale contenuto sono auto-esplicativi.

In AEM, questo contenuto viene implementato come componenti con modelli predefiniti molto semplici, che includono tutto ciò che può essere serializzato nel markdown e in HTML.

Il modello di questi componenti fa parte del Boilerplate per l'authoring WYSIWYG con Edge Delivery Services.

Blocchi blocks

I blocchi vengono utilizzati per creare contenuti più complessi con stili e funzionalità specifici. A differenza del contenuto predefinito, i blocchi richiedono una semantica aggiuntiva. I blocchi possono essere collegati a componenti nell’editor di pagine AEM.

I blocchi sono essenzialmente parti di contenuto arricchite da JavaScript e formattate con un foglio di stile.

Definizione modello del blocco model-definition

Quando si utilizza l’authoring WYSIWYG con i Edge Delivery Services, il contenuto dei blocchi deve essere modellato in modo esplicito per fornire all’autore l’interfaccia per la creazione dei contenuti. In sostanza, è necessario creare un modello in modo che l’interfaccia utente di authoring sappia quali opzioni presentare all’autore in base al blocco.

Il file component-models.json definisce il modello dei blocchi. I campi definiti nel modello del componente vengono mantenuti come proprietà in AEM e sottoposti a rendering come celle nella tabella che costituisce un blocco.

{
  "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"
    }
  ]
}

Tieni presente che non tutti i blocchi devono avere un modello. Alcuni blocchi sono semplicemente contenitori per un elenco di elementi secondari, in cui ognuno di essi ha un proprio modello.

È inoltre necessario definire quali blocchi esistono e possono essere aggiunti a una pagina utilizzando l’Editor universale. Il file component-definitions.json elenca i componenti man mano che vengono resi disponibili dall’Editor universale.

{
  "title": "Hero",
  "id": "hero",
  "plugins": {
    "xwalk": {
      "page": {
        "resourceType": "core/franklin/components/block/v1/block",
        "template": {
          "name": "Hero",
          "model": "hero"
        }
      }
    }
  }
}

È possibile utilizzare un modello per diversi blocchi. Ad esempio, alcuni blocchi possono condividere un modello che definisce un testo e un’immagine.

Per ogni blocco, lo sviluppatore:

Tutte queste informazioni vengono memorizzate in AEM quando un blocco viene aggiunto a una pagina. Se manca il tipo di risorsa o il nome del blocco, il blocco non verrà riprodotto sulla pagina.

Struttura del blocco block-structure

Le proprietà dei blocchi sono definite nei modelli di componenti e persistevano in quanto tali in AEM. Le proprietà vengono sottoposte a rendering come celle nella struttura di tipo tabella del blocco.

Blocchi semplici simple

Nella forma più semplice, un blocco esegue il rendering di ogni proprietà in una singola riga/colonna nell’ordine in cui sono definite nel modello.

Nell’esempio seguente, l’immagine viene definita prima nel modello e poi nel testo. Viene quindi eseguito il rendering prima dell’immagine e poi del testo.

{
  "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                            |
+---------------------------------------------+

Noterai che alcuni tipi di valori consentono di dedurre la semantica nel markup e che le proprietà vengono combinate in celle singole. Questo comportamento è descritto nella sezione Tipo di inferenza.

Blocco chiave-valore key-value

In molti casi, si consiglia di arricchire il markup semantico sottoposto a rendering, aggiungere nomi di classi CSS, aggiungere nuovi nodi o spostarli nel DOM e applicare stili.

In altri casi, tuttavia, il blocco viene letto come una configurazione di tipo coppia chiave-valore.

Un esempio sono i metadati della sezione. In questo caso d’uso, il blocco può essere configurato per eseguire il rendering come tabella di coppia chiave-valore. Per ulteriori informazioni, consulta la sezione Sezioni e metadati della sezione.

{
  "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                                                          |
+-----------------------------------------------------------------------+

Blocchi contenitore container

Entrambe le strutture precedenti hanno una singola dimensione: l’elenco delle proprietà. I blocchi contenitore consentono di aggiungere elementi secondari (di solito dello stesso tipo o modello) e sono quindi bidimensionali. Questi blocchi supportano ancora le relative proprietà sottoposte a rendering come righe con una singola colonna. Tuttavia, consentono anche di aggiungere elementi secondari, per i quali ogni elemento viene riprodotto come riga e ogni proprietà come colonna all’interno di tale riga.

Nell’esempio seguente, un blocco accetta un elenco di icone collegate come elementi secondari, dove ogni icona collegata ha un’immagine e un collegamento. Osserva l’ID filtro impostato nei dati del blocco per fare riferimento alla configurazione del filtro.

{
  "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) |
+-------------------------------------------------------------+

Creazione di modelli di contenuto semantico per blocchi creating-content-models

Con le spiegazioni sulle meccaniche della struttura del blocco, è possibile creare un modello di contenuto che mappa i contenuti persistenti in AEM uno a uno al livello di distribuzione.

All’inizio di ogni progetto, è necessario prendere in considerazione attentamente un modello di contenuto per ogni blocco. Deve essere indipendente dall’origine del contenuto e dall’esperienza di authoring per consentire agli autori di passare a un’altra origine o di combinarle riutilizzando al contempo le implementazioni e gli stili dei blocchi. Maggiori dettagli e indicazioni generali sono disponibili nel David’s Model (second take). In particolare, la raccolta blocchi contiene un ampio set di modelli di contenuto per casi d’uso specifici con pattern di interfaccia utente comuni.

Per l’authoring WYSIWYG con Edge Delivery Services, questo solleva la questione di come distribuire un modello di contenuto semantico convincente quando le informazioni vengono create con moduli composti da più campi invece di modificare il markup semantico in un contesto come il testo RTF.

Per risolvere questo problema, esistono tre metodi che facilitano la creazione di un modello di contenuto convincente:

Inferenza tipo type-inference

Per alcuni valori possiamo dedurre il significato semantico dagli stessi. Tali valori includono:

Tutto il resto verrà riprodotto come testo normale.

Comprimi campo field-collapse

La compressione del campo è il meccanismo che consente di combinare più valori di campo in un singolo elemento semantico basato su una convenzione di denominazione che utilizza i suffissi Title, Type, MimeType, Alt e Text (con distinzione maiuscole/minuscole). Qualsiasi proprietà che termina con uno qualsiasi di questi suffissi non sarà considerata un valore, ma piuttosto un attributo di un’altra proprietà.

Immagini 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]

Collegamenti e pulsanti 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")_

Titoli headings-collapse

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

<h2>Getting started</h2>

## Getting started

Raggruppamento elementi element-grouping

Mentre la compressione campo riguarda la combinazione di più proprietà in un singolo elemento semantico, il raggruppamento di elementi riguarda la concatenazione di più elementi semantici in una singola cella. Ciò è particolarmente utile per i casi d’uso in cui l’autore deve essere limitato nel tipo e nel numero di elementi che può creare.

Ad esempio, un componente teaser permette all’autore di creare solo un sottotitolo, un titolo e una singola descrizione di paragrafo combinati con un massimo di due pulsanti di invito all’azione. Raggruppando questi elementi insieme si ottiene un markup semantico a cui è possibile applicare uno stile senza ulteriori azioni.

Il raggruppamento di elementi utilizza una convenzione di denominazione, in cui il nome del gruppo è separato da ogni proprietà del gruppo da trattino basso. La compressione del campo delle proprietà in un gruppo funziona come descritto in precedenza.

{
  "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                          |
| ## Welcome to AEM                               |
| Join us in this ask me everything session ...   |
| [More Details](https://link.to/more-details)    |
| [RSVP](https://link.to/sign-up)                 |
+-------------------------------------------------+

Sezioni e metadati della sezione sections-metadata

Allo stesso modo in cui uno sviluppatore può definire e modellare più blocchi, si possono definire sezioni diverse.

Il modello di contenuto di Edge Delivery Services consente deliberatamente un solo livello di nidificazione, ovvero qualsiasi contenuto o blocco predefinito contenuto in una sezione. Ciò significa che per avere componenti visivi più complessi che possono contenere altri componenti, devono essere modellati come sezioni e combinati utilizzando il blocco automatico lato-client. Esempi tipici di ciò sono le schede e le sezioni comprimibili come i pannelli a soffietto.

Una sezione può essere definita nello stesso modo di un blocco, ma con il tipo di risorsa core/franklin/components/section/v1/section. Le sezioni possono avere un nome e un ID filtro, utilizzati soltanto dall’Editor universale, nonché un ID modello, utilizzato per eseguire il rendering dei metadati della sezione. Il modello è in questo modo il modello del blocco di metadati della sezione, che verrà automaticamente aggiunto a una sezione come blocco di valore-chiave, se non è vuoto.

L’ID modello e l’ID filtro della sezione predefinita è section. Può essere utilizzato per modificare il comportamento della sezione predefinita. L’esempio seguente aggiunge alcuni stili e un’immagine di sfondo al modello di metadati della sezione.

{
  "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
    }
  ]
}

L’esempio che segue definisce una sezione della scheda, che può essere utilizzata per creare un blocco di schede combinando sezioni consecutive con un attributo di dati del titolo della scheda in un blocco di schede durante il blocco automatico.

{
  "title": "Tab",
  "id": "tab",
  "plugins": {
    "xwalk": {
      "page": {
        "resourceType": "core/franklin/components/section/v1/section",
        "template": {
          "name": "Tab",
          "model": "tab",
          "filter": "section"
        }
      }
    }
  }
}

Metadati pagina page-metadata

I documenti possono avere una pagina blocco di metadati, utilizzata per definire quali elementi di <meta> vengono sottoposti a rendering nel <head> di una pagina. Le proprietà di pagina delle pagine in AEM as a Cloud Service corrispondono a quelle disponibili come predefinite per Edge Delivery Services, come title, description, keywords, ecc.

Prima di approfondire la definizione dei metadati, consulta i seguenti documenti, per comprendere il concetto di metadati della pagina.

È possibile inoltre definire metadati di pagina aggiuntivi in due modi.

Fogli di calcolo metadati metadata-spreadsheets

In AEM as a Cloud Service, è possibile definire i metadati per percorso o per modello di percorso in modo simile a una tabella. È disponibile un’interfaccia utente di authoring per i dati simili a tabelle simile a quella di Excel o Fogli Google.

Per creare tale tabella, crea una pagina e utilizza il modello Metadati nella console Sites.

Nelle proprietà di pagina del foglio di calcolo, definisci i campi di metadati necessari e l’URL. Quindi aggiungi i metadati per percorso pagina o pattern di percorso pagina.

Assicurati che il foglio di calcolo sia aggiunto anche alla mappatura del percorso prima di pubblicarlo.

{
  "mappings": [
    "/content/site/:/",
    "/content/site/metadata:/metadata.json"
  ]
}

Proprietà pagina page-properties

Molte delle proprietà di pagina predefinite disponibili in AEM sono mappate ai rispettivi metadati di pagina in un documento. Ciò include, ad esempio title, description, robots, canonical url o keywords. Sono disponibili anche alcune proprietà specifiche per AEM:

È possibile inoltre definire un modello di componente per i metadati della pagina personalizzati, che verrà reso disponibile all’autore come scheda della finestra di dialogo delle proprietà della pagina di AEM Sites.

Per farlo, crea un modello di componente con l’ID dei page-metadata.

{
  "id": "page-metadata",
  "fields": [
    {
      "component": "text",
      "name": "theme",
      "label": "Theme"
    }
  ]
}

Passaggi successivi next-steps

Ora che sai come modellare i contenuti, puoi creare blocchi per i tuoi Edge Delivery Services con il progetto di authoring WYSIWYG.

Per informazioni su come creare blocchi instrumentati per l'utilizzo con l'editor universale in WYSIWYG con progetti Edge Delivery Services, vedere il documento Creazione di blocchi instrumentati per l'utilizzo con l'editor universale.

Se hai già familiarità con la creazione di blocchi, consulta il documento Guida introduttiva per gli sviluppatori per l'authoring WYSIWYG con Edge Delivery Services per iniziare a utilizzare un nuovo sito Adobe Experience Manager con Edge Delivery Services e l'Editor universale per l'authoring dei contenuti.