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 di WYSIWYG con i 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.
- Testo: testo formattato (inclusi gli elementi dell’elenco e testo forte o in corsivo)
- Titolo: testo, tipo (h1-h6)
- Immagine: origine, descrizione
- Pulsante: testo, titolo, URL, tipo (predefinito, primario, secondario)
Il modello di questi componenti fa parte del Boilerplate per la creazione di 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 semantica aggiuntiva.
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:
- deve utilizzare il tipo di risorsa
core/franklin/components/block/v1/block
, l’implementazione generica della logica di blocco in AEM; - deve definire il nome del blocco, che verrà sottoposto a rendering nell’intestazione della tabella del blocco;
- Il nome del blocco viene utilizzato per recuperare lo stile e lo script corretti per decorare il blocco.
- può definire un ID modello.;
- L’ID modello è un riferimento al modello del componente, che definisce i campi disponibili per l’autore nel pannello delle proprietà.
- può definire un ID filtro.
- L’ID filtro è un riferimento al filtro del componente che consente di modificare il comportamento di authoring, ad esempio limitando quali elementi secondari possono essere aggiunti al blocco o alla sezione o quali funzioni dell’editor Rich Text sono abilitate.
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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:
- Immagini: se un riferimento a una risorsa in AEM è una risorsa di tipo MIME che inizia con
image/
, il riferimento viene sottoposto a rendering come<picture><img src="${reference}"></picture>
. - Collegamenti: se esiste un riferimento in AEM e non è un’immagine, o se il valore inizia con
https?://
o#
, il riferimento viene sottoposto a rendering come<a href="${reference}">${reference}</a>
. - Rich Text: se un valore troncato inizia con un paragrafo (
p
,ul
,ol
,h1
-h6
, ecc.), il valore viene sottoposto a rendering come testo RTF. - Nomi classi - La proprietà
classes
viene trattata come opzioni blocco ed è rappresentata nell'intestazione della tabella per blocchi semplici, o come elenco valori per gli elementi in un blocco contenitore . È utile se si desidera formattare un blocco in modo diverso, ma non è necessario creare un blocco completamente nuovo. - Elenchi valore: se un valore è una proprietà con più valori e il primo valore non è nessuno dei precedenti, tutti i valori vengono concatenati come elenco separato da virgole.
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
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Collegamenti e pulsanti links-buttons-collapse
code language-json |
---|
|
No linkType
o linkType=default
code language-html |
---|
|
linkType=primary
code language-html |
---|
|
linkType=secondary
code language-html |
---|
|
code language-text |
---|
|
Titoli headings-collapse
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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 ulteriori dettagli, vedere il documento Utilizzo dei fogli di calcolo per gestire i dati tabulari per ulteriori informazioni.
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:
cq:lastModified
comemodified-time
in formato ISO8601- Ora dell’ultima pubblicazione del documento come
published-time
in formato ISO8601 cq:tags
comecq-tags
come elenco separato da virgole degli ID dei tag.
È inoltre possibile definire un modello di componente per i metadati di pagina personalizzati, che sarà reso disponibile all’autore nell’Editor universale.
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 di WYSIWYG.
Consulta il documento Creazione di blocchi instrumentati per l'utilizzo con Universal Editor per scoprire come creare blocchi instrumentati per l'utilizzo con Universal Editor nei progetti di creazione di Edge Delivery Services in WYSIWYG.
Se hai già familiarità con la creazione di blocchi, consulta il documento Guida introduttiva per gli sviluppatori per l'authoring di WYSIWYG con i Edge Delivery Services per iniziare a utilizzare un nuovo sito Adobe Experience Manager con i Edge Delivery Services e Universal Editor per l'authoring dei contenuti.