Passa al contenuto principale

Concetti

Properties​

Una property rappresenta un progetto/sito web. Il Discovery CMS permette di gestire più properties, che possono corrispondere ad altrettanti siti web.

La property definisce alcune proprietà quali:

  • URL degli ambienti produzione, test, development, etc.
  • lingue del sito (es. Inglese, Italiano)
  • token di accesso ai vari ambienti (sviluppo, test, produzione)
  • utenti autorizzati a lavorare sulla property

Pages​

Una page rappresenta una pagina del sito web. Una pagina ha una URL che può essere inserita nel browser e visualizzata. Esempi di pagine sono: landing pages, about page, contact page. Queste pagine hanno una URL univoca, di cui la prima parte dipende dalla property a cui appartiene la pagina (dominio/path del sito) e l'ultima parte è lo slug della pagina, inserito al momento della creazione delle pagina.

Lo slug permette di utilizzare un nome "parlante" per la pagina, visibile nella URL, utilizzato anche per migliorare il SEO della pagina. Esempio di slug validi:

  • '2022-05-02-notizie-del-giorno'
  • '/2022/05/02/notizie-del-giorno'

Come si vede nell'esempio sopra, Discovery CMS supporta slug che contengono '/', in forma di path. Gli unici caratteri ammessi sono lettere, numeri, '-' e '/'. Quando si sviluppa l'app di frontend, è possibile utilizzare un connettore per recuperare, tramite chiamata REST, la struttura della pagina. Per identificare la pagina da recupeare viene appunto utilizzato lo slug.

Oltre alle pagine tradizionali, ci sono altre due tipologie di pagine:

  • pagine template: sono pagine che servono a rappresentare un singolo contenuto. Un esempio è una pagine di dettaglio prodotto o una pagina con l'articolo di un sito news: queste pagine hanno sempre bisogno di un content (es. codice prodotto o slug articolo).
  • pagine layout: sono pagine che contengono gli elementi comuni all'intero sito, come ad esempio l'header, il footer, il menu di navigazione. Le pagine di layout sono anche adatte a gestire la palette di colori del sito.

Le pagine sono logicamente divise in componenti (components), per semplificarne l'editing.

Components​

I components sono i "mattoni" con cui la pagina è costruita. Nel nostro modello i mattoni sono macro componenti: all'editor non vengono forniti singoli bottoni, label, e altri elementi base per costruire la pagina, in quanto questa eccessiva granularità complicherebbe notevolmente la costruzione della pagina. Piuttosto, un team di specialisti costruisce i macro componenti, rispettando delle regole di UI/UX, e all'editor viene data la possibilità di:

  • inserire/spostare/rimuovere components
  • modificare gli elementi nei components senza bypassare le regole di stile.

Ad esempio, la property "Reply.com" può contenere un content "Home Page" che a sua volta è composto da più componenti:

  • Header
  • Call To Action
  • Campaign
  • Testimonials
  • Footer

Ogni component può avere dei fields, quali ad esempio headline, testo della call to action, colore del bottone, link a cui punta un bottone etc. Se la property è multilingua, alcuni di questi fields possono essere multilingua.

I components corrispondono ad altrettanti componenti nella tecnologia di frontend (es. ReactJS). Un component appartiene sempre ad una pagina e non può essere creato fuori dal contesto di una pagina.

Contents​

I contents sono contenuti strutturati, composti da un insieme di fields. Esempio classico di content è un articolo di news, un post o una scheda prodotto con relative immagini.

I content possono essere visualizzati solo nell'ambito di una pagina template. I content possono essere visti come i dati, mentre la pagina può essere vista come la sua presentation. Quando si pensa ad un content, infatti, bisogna pensare solo ai suoi dati, non alla sua presentazione. Sarà compito della pagina presentarlo. Tecnicamente è possibile anche rappresentare lo stesso content (es. articolo) con due pagine diverse, ad esempio una ottimizzata per smartphone e una per il web.

I contents possono essere di due tipi:

  • definiti dall'utente
  • forniti da Reply (in ambito progettuale)

I content forniti da Reply possono includere personalizzazioni più avanzate rispetto ai content definiti dall'utente.

Type​

Type in questo contesto viene usato come abbreviazione di Content Type. Un type definisce la struttura, in termini di campi (fields) che lo compongono, di un component o di un content. Un type può essere creato dall'utente, ad esempio, per definire la struttura dei suoi content di tipo Articolo. Quando si definisce un type si indicano i fields di cui è composto, e per ogni field viene indicato il tipo e le caratteristiche. Ad esempio, per il type Articolo posso avere come fields:

  • headline: string, multilanguage
  • topic: taxonomy "Topics", single value
  • images: link to DAM image
  • body: richtext with advanced editor
  • tags: taxonomy "Tags", multiple values

Un tipo può essere:

  • private: visibile soltanto all'interno della property in cui è definito,
  • global: condiviso tra tutte le properties

Tipicamente i tipi global fanno riferimento ad entità aziendali che si vuole mettere a fattor comune. Un esempio tipico è il type Prodotto: in un'azienda che ha un catalogo prodotti è probabile che possano esistere più properties che hanno bisogno di riferire prodotti, per cui ha senso definire il tipo Product come global.

Altri tipi, invece, possono essere molto verticali per una specifica property. In tal caso devono essere definiti come private, in modo da non creare troppe dipendenze tra le properties.

Pubblicazione​

Sia i contenuti (contents) che le pagine (pages) vengono pubblicate verso la Content API, un layer di pubblicazione cloud disaccoppiato dal backend del CMS e che sfrutta nativamente servizi cloud AWS. I componenti non vengono mai pubblicati direttamente, ma sempre tramite la pubblicazione delle pagine a cui appartengono.

Al fine di fornire un servizio di anteprima delle modifiche agli editori prima che le vedano gli utenti finali, vengono pubblicate due versioni dei contenuti e delle pagine:

  • preview: visibile solo agli editori
  • public: visibile a tutti

Per questo motivo, quando viene creata una property vengono generati due token che, una volta passati all'API, recuperano la versione preview o la versione public. Solo gli editori hanno accesso al token di preview, e pertanto un utente esterno non potrà mai vedere i contenuti e le pagine prima che siano definitivamente pubblicate.

Quando l'editore entra in modifica nel CMS su un contenuto o una pagina, nel momento in cui salva viene automaticamente aggiornata solo la versione di preview, e di conseguenza aggiornata l'anteprima del sito o applicazione. Quando l'editore è sicuro delle modifiche, effettua la vera pubblicazione, creando o aggiornando la versione public, in modo che gli utenti finali possano vederla.

Per questo motivo, all'interno del CMS esiste un bottone "Save", che aggiorna la preview, ed un'area dove gestire la pubblicazione. Per organizzazioni con molti utenti, potrebbero anche essere separati gli utenti che possono aggiornare pagine e contenuti di preview dagli utenti che effettivamente approvano la pubblicazione verso gli end user del sito/applicazione. Tutto ciò può essere anche inserito in un workflow che coinvolge più utenti, come ad esempio degli utenti revisori che possono rimandare le pagine agli editori chiedendo delle modifiche.

Una volta che la pagina viene pubblicata, lo stato persiste anche in caso di modifiche. In tal caso, nel caso vengano fatte delle modifiche sulla versione di preview, è necessario usare il bottone "Republish" per aggiornare la versione public, pubblicando le modifiche anche verso l'esterno.

Conclusioni​

Questi sono i concetti fondamentali da aver chiari quando si lavora con il Discovery CMS. Riassumendo:

  • property: rappresenta un progetto
  • page: rappresenta una pagina web o una pagina template (es. la pagina per visualizzare articoli)
  • component: sono i mattoni base di cui è composta una page, generalmente corrispondenti a componenti ReactJS, VueJS, etc.
  • content: sono contenuti strutturati, quali prodotti, articoli, etc. Sono i dati che poi verranno visualizzati tramite le pagine templates.
  • type: definisce la struttura di un content (esempio: titolo, descrizione, etc.)
  • pubblicazione: è la fase in cui i dati vengono pubblicati verso l'API utilizzata dal frontend, che consiste in una versione anteprima e una versione pubblica.