Quasi tutti i siti aziendali tengono il testo dentro l’HTML, ed è per questo che rifare la grafica costa quanto rifare il sito. Un sistema di gestione dei contenuti serve a spezzare quel legame: il contenuto da una parte, la sua resa visiva dall’altra, e la pubblicazione che passa per regole esplicite invece che per un trasferimento FTP fatto a mano. A gennaio 2003 l’alternativa Open Source a questo problema ha smesso di essere sperimentale.

Contesto e problema

Sotto l’etichetta “content management system” finiscono cose molto diverse: il motore di un sito di notizie come Slashcode, lo strumento di redazione documentale di una grande organizzazione. Il problema di fondo però non cambia. Un contenuto ha un autore, una data, una lingua, uno stato (bozza, in revisione, pubblicato) e una o più rese: pagina web, feed, stampa. Mettere tutto questo dentro file .html vuol dire duplicare la struttura a ogni pagina e rinunciare a interrogare l’archivio per metadato.

La risposta classica del mercato proprietario è un prodotto chiuso che salda contenuto, database e template in un blocco solo, spesso con licenze a CPU e un costo che cresce con il numero di redattori. La risposta Open Source di cui mi occupo qui parte da tutt’altro punto: un application server generico con un proprio database a oggetti, e sopra un framework dedicato alla gestione dei contenuti.

Architettura

Il caso più maturo, oggi, è Zope (Z Object Publishing Environment), un application server scritto in Python. La sua caratteristica strutturale è la persistenza a oggetti: ZODB (Zope Object Database), il database integrato, salva istanze Python come oggetti in un albero gerarchico, senza il passaggio di mappatura verso le tabelle relazionali. Un documento, una cartella, un’immagine sono oggetti che si raggiungono per URL scendendo lungo la gerarchia di contenimento — il modello di pubblicazione di Zope traduce un percorso URL direttamente in una traversata dell’albero degli oggetti.

Sopra Zope gira il Content Management Framework (CMF), un insieme di strumenti che porta i concetti tipici della gestione redazionale. I componenti principali sono:

  • portal_types: il registro dei tipi di contenuto. Un tipo (Document, News Item, Link, Image) è una classe Python di qualche centinaio di righe, che si estende o si sostituisce;
  • portal_skins: il livello di presentazione. I template (DTML e Zope Page Templates) stanno in cartelle a strati, e una richiesta risolve il template attraversando gli strati dal più specifico al più generico. Cambiare l’aspetto del sito vuol dire cambiare uno strato, non toccare i contenuti;
  • portal_workflow: la macchina a stati che descrive il ciclo di vita. Lo stato private passa a pending con la transizione submit, e a published con publish, dove il permesso sulla transizione di approvazione spetta al ruolo Reviewer;
  • portal_catalog: l’indice. Ogni oggetto contenuto viene catalogato per i suoi metadati e per il testo, e diventa interrogabile senza che l’amministratore configuri gli indici a mano.

Quel che conta, sul piano architetturale, è la separazione fra questi quattro strumenti: il tipo dice cosa è un contenuto, lo skin come appare, il workflow chi ne può cambiare lo stato, il catalog come lo si ritrova.

Punto critico

Il metadato non è un dettaglio amministrativo: senza, un archivio non si interroga e non si fa parlare con altri sistemi. A ogni contenuto CMF associa un insieme di proprietà — titolo, descrizione, autore, data di creazione e di modifica, soggetto — che ricalca i quindici elementi del Dublin Core, lo schema di descrizione delle risorse standardizzato in RFC 2413. È lo stesso vocabolario che WebDAV (RFC 2518) usa per esporre le proprietà di una risorsa come elementi XML in uno spazio dei nomi.

In pratica, un contenuto descritto con metadati standard non resta prigioniero del CMS che lo ha prodotto. Si può indicizzare, esportare, riusare su un altro canale. Un sistema proprietario che si inventa il proprio schema di metadati arriva allo stesso risultato funzionale dentro il prodotto, ma chiude la porta verso l’esterno. Qui l’Open Source, al di là della licenza del codice, porta un valore citato di rado: l’aderenza a formati e protocolli pubblici, perché chi scrive software libero non ha alcun interesse a costruire lock-in di formato.

Implicazioni

A oggi l’offerta Open Source per il content management è già ampia. Accanto a Zope/CMF ci sono OpenCms, motore Java in sviluppo come progetto libero dal 2000; Midgard, che gira sullo stack LAMP — Linux, Apache, MySQL e PHP — con un proprio modello a oggetti; e una lunga lista di motori più verticali per portali e siti di notizie. Sul ramo CMF è in sviluppo un livello di presentazione, Plone, che mette a disposizione skin e interfaccia redazionale già pronte sopra il framework.

Per chi sta valutando una soluzione enterprise, la domanda non è “Open Source o proprietario” in astratto. È più concreta: il sistema separa davvero contenuto, presentazione e workflow? Espone i contenuti con metadati standard? Lascia estendere un tipo di contenuto senza riscrivere il motore? Su questi tre criteri un framework come CMF se la gioca alla pari con i prodotti chiusi, e in più tiene leggibile e modificabile ogni riga — i tipi di contenuto di CMF sono file Python di qualche centinaio di righe, non scatole nere.

Limiti

Restano dei vincoli onesti da mettere sul tavolo. La curva di apprendimento di Zope è ripida: il modello a oggetti, l’acquisizione (acquisition) e il sistema di sicurezza chiedono di ragionare in modo diverso dalla coppia PHP più database relazionale a cui molti sono abituati. La persistenza ZODB è efficiente in lettura, ma vuole attenzione sulle transazioni di scrittura concorrenti e sulla crescita del file Data.fs, che va impacchettato di tanto in tanto. Il livello CMF è ancora in evoluzione e l’interfaccia redazionale di base, senza uno strato come Plone, è spartana. Niente di tutto questo toglie validità all’architettura; serve solo a ricordare che “Open Source maturo” vuol dire maturo come progetto, non senza costi di adozione.

Chi vuole verificare di persona trova codice e documentazione pubblici, e può tirare su un’istanza CMF su una macchina di prova in un pomeriggio. È il modo migliore per capire se la separazione fra contenuto e presentazione regge sul proprio caso d’uso, invece di fidarsi di una slide.

Questi stessi temi sono al centro dell’IDC Content Management Seminar, dove noze è fra gli espositori; il resoconto è nell’insight pubblicato da noze: https://www.noze.it/insights/idc-content-management/.

https://www.zope.org/ https://www.zope.org/Products/CMF/ https://www.opencms.org/ https://www.midgard-project.org/ https://www.ietf.org/rfc/rfc2413.txt https://www.ietf.org/rfc/rfc2518.txt https://dublincore.org/

Immagine di copertina: Diagramma concettuale di Enterprise Content Management che mostra le fasi di cattura, gestione, archiviazione, distribuzione e… — diagramma di ModriDirkac, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:AIIM_ECM_SLO_Scheme.png