Passa al contenuto principale

Concetti

Prima di iniziare a sviluppare un'applicazione di frontend è fondamentale aver compreso i concetti alla base e l'approccio proposto dal Discovery CMS. Al contrario dei CMS tradizionali, che erogano pagine HTML direttamente al browser, il Discovery CMS ha un approccio headless: i frontend, che siano siti web o applicazioni, vengono sviluppati utilizzando un qualsiasi framework di frontend (es. React o Vue), oppure utilizzando approcci server-side (PHP, Python...). Il ruolo del CMS, in questo caso, è quello di mettere a disposizione i contenuti e le pagine tramite API, lasciando a chi realizza il frontend la scelta di organizzare la visualizzazione di questi contenuti/pagine.

Il frontend può essere realizzato, dunque, in qualsiasi tecnologia che sia in grado di consumare un'API REST (e, nella prossima versione del CMS, GraphQL). Tuttavia, se si utilizza un framework basato su Javascript, il Discovery CMS mette a disposizione un connettore che:

  • facilita la comunicazione tra frontend e backend
  • permette di costruire sul backend del CMS le pagine utilizzando, come mattoni, i componenti React/Vue/etc. che vengono messi a disposizione degli editori

I vantaggi del Discovery CMS sono dunque:

  • accesso dinamico, da parte dell'applicazione, a tutti o parte dei contenuti, senza dover rilasciare una nuova versione quando, ad esempio, cambia un'immagine hero in una pagina;
  • possibilità, per gli amministratori del sito/app, di creare nuove pagine o modificare quelle esistenti utilizzando una libreria di componenti messi a disposizione dagli sviluppatori.

Qualora, per qualche motivo, non si voglia permettere agli amministratori di modificare la struttura delle pagine, ad esempio perché si potrebbe violare qualche logica applicativa, è naturalmente possibile inibire questa possibilità.

Vista Anteprima vs Produzione​

Al fine di consentire gli aggiornamenti dei contenuti quando il sito è già in produzione, il Discovery CMS fornisce sempre due viste dei dati:

  • vista anteprima: è la vista che viene aggiornato quando si salva come bozza (draft)
  • vista produzione: è la vista che viene aggiornata quando si pubblica

Il normale flusso di lavoro prevede che i dati vengano aggiornati e salvati come bozza, eventualmente attivando dei flussi di revisione da parte di altri utenti se necessario.

Solo quando i contenuti sono da pubblicare agli end users, vengono portati da stato "draft" a stato "published". Naturalmente, nei casi in cui non sia necessaria alcuna revisione e si voglia aggiornare subito il sito pubblico, è possibile evitare di salvare come draft e pubblicare direttamente le modifiche.

E' importante tener presente che la vista anteprima si riferisce solo alla pagina o contenuto che si sta editando. Se la pagina/contenuto corrente riferisce, tramite un field di tipo Reference, altri contenuti, nell'anteprima viene recuperata la vista pubblicata del contenuto riferito. Ad esempio, supponiamo di aver aperto una home page nel Page Editor che riferisce un prodotto "T-Shirt Red". E' possibile che qualcuno abbiamo modificato il titolo del prodotto riferito, ma che non l'abbia ancora pubblicato. Nell'anteprima della pagina sarà mostrato sempre "T-Shirt Red" e non il titolo con le ultime modifiche. In questo modo si assicura che l'anteprima della pagina o contenuto sia fedele a quello che gli utenti vedranno appena la pagina o il contenuto corrente vengono pubblicati in produzione.

API Personalizzate​

Il Discovery CMS offre una REST API standard (e, in futuro, GraphQL API) che può essere usata dalle applicazioni di frontend per recuperare i contenuti dal repository. Oltre alle API del CMS, tuttavia, l'applicazione potrebbe aver bisogno di ulteriori API, ad esempio per interagire con altri sistemi o offrire funzionalità non incluse nel CMS.

In questo caso sono possibili due approcci:

  • utilizzare un set di API in aggiunta alle API del CMS: è possibile utilizzare un proprio strato di API in aggiunta a quelle fornite dal CMS;
  • estendere le API del CMS creando degli endpoint specializzati che possono facilitare o ottimizzare le interazioni da parte dell'applicazione con il CMS stesso.

La prima soluzione può essere adottata in completa autonomia, mentre per l'estensione/personalizzazione delle API del CMS è necessario avvalersi di Professional Services offerti da Reply.