Content Model

Nella sezione Type è possibile configurare il content model della property corrente. Il content model è l'insieme dei tipi configurati per creare Contents o Components. Ogni Content o Component ha una struttura ben definita in termini di Fields che lo compongono.

Ad esempio, il Content Type "Article" può essere configurato con la seguente struttura:

• Title: field di tipo String
• Slug: field di tipo String
• Description: field di tipo Richtext
• Immagine: field di tipo Image

Una volta definita la struttura del content type "Article", nella sezione Contents è possibile creare articoli che avranno esattamente questa struttura. E' importante che sia nota la struttura dei content types e dei componenti in quanto il frontend ottiene questi field tramite API e ne deve conoscere la struttura per poterne preparare la presentazione a schermo.

I Type che costituiscono il Content Model vengono creati nella sezione CMS > Types. Una volta scelto il nome del type e specificato se si tratta di un Content (es. Articolo) o di un Component (sezione di una pagina, es. CallToAction), si accede ad una pagina dov'è possibile scegliere il set di Fields che compongono il Type cliccando su uno dei Field Types disponibili a sinistra (String, Richtext, etc.):

Deployment

IMPORTANTE: una volta configurati o modificati i Content Types, è necessario cliccare sul bottone Deploy affinché le modifiche siano visibili nel resto del CMS. Finché non viene eseguito il deployment, resta la configurazione precedente.

Opzioni Comuni

Dopo aver selezionato un field type nella barra di sinistra, appare una modale di configurazione. Le opzioni disponibili dipendono dal field type selezionato. Ad esempio, per field type String appare la seguente modale:

Ci sono una serie di opzioni comuni a (quasi) tutti i field types:

• Settings > API Field Name (obbligatorio): permette di specificare il nome che questo campo avrà nel JSON restituito dall'API. Si
• Settings > Label: permette di specificare il nome che questo campo avrà nella form del backend di amministrazione Discovery. Di default, viene utilizzato l'API Field Name, ma è possibile scegliere un nome meno tecnico.
• Settings > Short Description: permette di specificare una breve descrizione (poche parole) che deve apparire sotto il campo nella form di amministrazione Discovery. Questa descrizione può essere d'aiuto agli editori per capire cosa inserire nel campo, qualora non fosse chiaro dal nome del campo stesso.
• Validation > Required: se selezionato, il contenuto/componente relativo non potrà essere pubblicato se questo field non è valorizzato.
• (previsto per le releases future) Validation > Unique: se selezionato, questo campo deve contenere un valore unico. Ad esempio, un field ProductCode potrebbe avere il vincolo di essere unico.
• Other > Hide in API: se selezionato, questo campo non viene reso visibile tramite API. Tuttavia, potrà essere utilizzato per le ricerche. Uso avanzato. IMPORTANTE: se viene modificata quest'opzione, i relativi contenuti vanno ripubblicati perché abbia effetto.
• Other > Available in Listing API: se selezionato, questo campo verrà restituito dalla listing API, ovvero gli endpoint che recuperano più risultati (es. getContents()), in modo da limitare la dimensione del documento JSON restituito dalle API. getContents() restituisce solo l'ID o slug dei contenuti filtrati, il titolo, più tutti gli attributi che sono stati selezionati con quest'opzione. E' consigliabile limitare allo stretto necessario i campi restituiti dalle API di ricerca, in quanto generalmente nel listing dei risultati vengono visualizzati solo pochi attributi, in modo da rendere più efficienti le ricerche. Il campo, tuttavia, sarà sempre visibile nell'API che restituisce tutti gli attributi a partire dall'identificativo del contenuto. Quest'opzione ha senso in particolare per i Type di tipo Content. IMPORTANTE: se viene modificata quest'opzione, i relativi contenuti vanno ripubblicati perché abbia effetto.
• Other > Default Value: per alcuni field type è possibile specificare il valore di default che questo campo dovrà avere alla creazione del relativo content/component. IMPORTANTE: il default value viene applicato solo ai Content/Component che verranno creati dopo averlo specificato. Qualora siano stati già creati Content/Component del tipo che si sta configurando e si imposti il default value, questo non avrà effetto retroattivo.

String

Utilizzato per campo di tipo stringa semplici, ovvero che non contengono formattazione. Oltre alle opzioni comuni, è possibile indicare:

• Settings > Number of lines: indica il numero di linee dell'editor sul backend (1 o più)
• Settings > Multilanguage: indica che il campo avrà una variante di lingua. Quest'opzione va utilizzata solo per le properties multilingua. Nella form di amministrazione della property è possibile indicare l'elenco delle lingue.
• Validation > Length: lunghezza massima della stringa.
• Validation > Match a specific pattern: permette di inserire una regular expression che il field dovrà onorare (vedi sotto).
• Validation > Custom Validator: permette di indicare un custom validator (ad oggi, solo Reply può fornire custom validators).
• Other > Use as Title: se selezionato, sul backend Discovery verrà utilizzato questo field come titolo nel listing.

Regular Expressions

Per le espressioni regolari, occorre fornire un pattern valido per la funzione preg_match. Per costruire la regular expression, è possibile testarle utilizzando il sito regex101.com (selezionare PCRE2 a sinistra).

Richtext

Sono speciali tipi di campi stringa che possono includere formattazione. Di default vengono fornite poche possibilità di formattazione, in modo da limitare le possibilità dell'editor a caratteri in grassetto, corsivo, e poche altre possibilità di formattazione.

Per questi campi è possibile selezionare un'opzione "Advanced Richtext" per avere pieno accesso a tutte le possibilità dell'editor HTML, inclusa la possibilità di modificare direttamente l'HTML. E' possibile usare quest'opzione, ad esempio, per lasciare la possibilità di creare pagine HTML a layout libero, seguendo uno stile "classico" anziché "headless", dove i contenuti sono strutturati in modo da essere visualizzabili su più touchpoints.

Per visualizzare questo tipo di campi in React è necessario utilizzare l'attributo dangerouslySetInnerHTML, come nell'esempio seguente, in quanto React per motivi di sicurezza non mostra attributi HTML contenuti nei dati:

<div dangerouslySetInnerHTML={{ __html: componentData.fields.body ?? '' }} />

Image & Video

Utilizzare questi tipi di campi quando si vogliono inserire immagini o video in un componente o contenuto. Il backend permetterà di scegliere immagini o video presenti nel DAM integrato oppure di caricarli dal proprio file system.

E' possibile effettuare il ritaglio (crop) delle immagini tramite l'apposita icona.

Qualora si voglia dare la possibilità di scegliere qualsiasi tipo di asset digitale (immagini, video, documenti, ...), utilizzare il tipo Reference.

L'opzione Settings > Use as Content Preview permette di impostare un campo immagine o video come antemprima del contenuto. Di default, viene utilizzato il primo field immagine o video presente. Con quest'opzione è possibile modificare il default.

Alla versione 1.0 non è possibile configurare immagini e video multipli. Questa limitazione verrà superata nelle versioni successive. Come workaround, utilizzare il tipo Reference, ma in tal caso le immagini devono essere caricate già tagliate.

Reference

Permettono di indicare che un field che riferisce altri Content o Components (a seconda del Content Type che stiamo configurando). E' possibile restringere il riferimento ad uno specifico type o lasciare libero (Any). E' possibile indicare se la scelta è singola o multipla. Se la scelta è multipla, nel pannello Validation è possibile limitare il numero di scelte. Lasciando vuoto quest'opzione, le scelte sono illimitate.

Lato backend, per questi field viene presentato un picker che permette di scegliere tra i contenuti disponibili nel Discovery.

Taxonomy

Permette di legare un field ad una tassonomia definita in Discovery. E' possibile scegliere la tassonomia a cui legarlo e indicare se le scelte devono essere singole o multiple. L'opzione Other > Allow New Terms permette di indicare se l'utente di backend ha il permesso di inserire nuovi termini on-the-fly nella tassonomia, semplicemente digitandoli. Quest'opzione dev'essere usata con cautela, in particolare quando gli utenti di backend sono molti, in quanto c'è il rischio di "inquinare" quelli che dovrebbero essere dizionari controllati.

Link

Permette di specificare che un campo è un link verso un'altra pagina. Ad esempio, un componente CallToAction potrebbe avere un field con un link verso la pagina in cui navigare quando l'utente clicca sul bottone dell'action. Le pagine possono essere interne al sito o esterne (es. https:://www.reply.com).

Number

Attraverso i campi di tipo number è possibile inserire solamente un valore numerico, è possibile definire attraverso l'attributo type il tipo del valore accettato (ad esempio integer o double).

Enumerate

Questo tipo di campo permette di definire i valori della select che verrà visualizzata all'interno del componente nel page editor. Il campo Enumerate è simile al campo Taxonomy, ma in genere le Enumerate vengono utilizzate per pochi valori e quando la stessa enumerazione non dev'essere condivisa tra più componenti/contenuti. Infatti, l'elenco dei valori inseriti nella configurazione non potrà essere riutilizzato. E' possibile vedere Enumerate come una versione "light" di Taxonomy. La comodità del campo Enumerate è che non richiede la creazione di una tassonomia.

Color Picker

Il color picker permette all'utente di scegliere un colore attraverso un picker grafico, il quale restituirà il codice del colore scelto.

Boolean

Permette di definire un Field dove l'unica scelta possibile è vero/falso. A meno che non sia stato inserito un valore di default per il campo boolean, finché non viene selezionato alcun valore nel Page Editor, il field non viene ritornato dall'API (in quanto vuoto).

Date and Datetime

Con i field type Date e Datetime è possibile aggiungere campi che accettano una data nel formato aaaa/mm/gg, oppure, nel caso datetime, aaaa/mm/gg hh:mm.

Quando si effettuano ricerche tramite API, è necessario considerare il formato del search engine, che sarà il seguente: yyyy-mm-ddThh:mm:ssZ, ad esempio: "2023-02-23T10:15:00Z".

JSON (da v.1.1)

Permette di inserire direttamente un frammento JSON che verrà restituito poi dall'API. Utile qualora nessuno dei field type disponibile sia adatto a rappresentare una struttura di cui necessita il frontend.

Role

Aggiungendo un nuovo campo con type: role l'utente avrà la possibilità di scegliere, attraverso una select, tra tutti i ruoli definiti all'interno di Discovery. Con l'attributo multiselect: true si abilita la possibilità di scegliere più di una opzione.

User

Aggiungendo un nuovo campo con type: user l'utente avrà la possibilità di scegliere, attraverso una select, tra tutti gli utenti definiti all'interno di Discovery. Con l'attributo multiselect: true si abilita la possibilità di scegliere più di una opzione.