Da pochi giorni esiste in Italia un’associazione dedicata a chi usa l’application server Zope e i prodotti che gli stanno sopra, Plone per primo. La notizia in sé è organizzativa, ma il motivo per cui un coordinamento nazionale serve è tecnico, e preferisco metterlo nero su bianco.

Contesto

Zope è un application server scritto in Python, rilasciato nel 1998 da Digital Creations (oggi Zope Corporation). Tiene gli oggetti in un suo database transazionale, lo Zope Object Database (ZODB), scritto da Jim Fulton: invece di mappare le classi Python su tabelle relazionali, persiste gli oggetti così come sono, con commit e rollback per transazione. Sopra Zope gira il Content Management Framework (CMF), e sopra il CMF gira Plone, la cui serie 2.0 è uscita nel marzo 2004.

È uno stack coerente e poco diffuso. Coerente perché un’unica idea — oggetti persistenti, gerarchia di contenitori, template — attraversa tutti i livelli. Poco diffuso perché quell’idea non somiglia a quasi nient’altro nel web del 2005, dove dominano LAMP e i framework che partono dal database relazionale. Chi sceglie Zope in Italia si ritrova così con strumenti potenti e pochi colleghi sul territorio a cui chiedere aiuto. È proprio il vuoto che un’associazione di utenti può riempire.

Il modello di programmazione da spiegare

Tre meccanismi di Zope spiegano insieme la sua produttività e la sua curva di apprendimento ripida, e sono i punti dove una comunità locale decide se uno arriva all’adozione o molla.

Il primo è l’acquisition. Un oggetto dentro una cartella può ereditare attributi e metodi dei suoi contenitori risalendo la gerarchia: una query SQL o un pezzo di template scritti una volta in alto sono visibili a tutti gli oggetti sotto, senza ridichiararli. È il meccanismo che centralizza le risorse comuni, ma è anche quello che genera comportamenti spiazzanti quando la risoluzione di un nome sale un livello che non ti aspetti. Negli altri stack da cui arrivano gli sviluppatori non esiste, e va insegnato.

Il secondo sono le Zope Page Templates (ZPT) con il Template Attribute Language (TAL). Un template ZPT è HTML valido in cui la logica sta negli attributi tal: sui tag già presenti, così il documento resta apribile e visualizzabile come pagina statica anche prima del rendering. È una scelta progettuale precisa — il template rimane un file che un grafico può ritoccare — lontana dall’interpolazione testuale dei sistemi che stampano stringhe.

Il terzo è lo sviluppo through-the-web (TTW): buona parte dell’applicazione la costruisci dall’interfaccia del browser, scrivendo codice e template che finiscono nel ZODB insieme ai dati. Comodo per partire, scomodo per il versionamento, perché il codice vive nel database e non in file su cui far girare cvs o svn. Qui le pratiche di squadra non sono ovvie e si tramandano per esperienza diretta più che per documentazione.

Punto critico: la persistenza non è il database relazionale

Il nodo che più spesso manda fuori strada chi arriva da MySQL o PostgreSQL è che il ZODB non è un sistema relazionale e non lo interroghi con SQL. Si naviga la gerarchia degli oggetti, e la concorrenza in scrittura su un singolo storage va gestita a mano.

La risposta architetturale di Zope è ZEO (Zope Enterprise Objects), del 2001: un modello client-server in cui un processo ZEO server custodisce lo storage condiviso — di solito un FileStorage — e più client Zope vi si collegano tramite uno storage pluggable, con cache lato client. Così scali in orizzontale i processi applicativi su una sola base dati, ma sposti la complessità sulla gestione dei conflitti (ConflictError) quando due transazioni toccano lo stesso oggetto. Risolverli bene vuol dire scrivere metodi _p_resolveConflict sugli oggetti persistenti, ed è conoscenza che gira nelle liste e alle conferenze, non nei manuali introduttivi.

Aggiungo un elemento che nel 2005 pesa parecchio: la frattura tra le linee di sviluppo. Zope X3 3.0.0, prima release di produzione della riscrittura a componenti, è uscita il 6 novembre 2004 e non è compatibile con Zope 2 — le applicazioni Zope 2, e quindi Plone, su quella linea non girano. Chi pianifica oggi un progetto deve scegliere con cognizione su quale linea investire, e per orientarsi in questa transizione una comunità che ci è già passata conta più di qualunque white paper.

Cosa cambia per chi sviluppa qui

Un’associazione nazionale di utenti incide su tre cose concrete. Mette in contatto le poche aziende e i pochi sviluppatori che sullo stesso territorio sbattono contro gli stessi problemi di acquisition, conflitti ZEO e migrazione, accorciando il tempo speso a reinventare soluzioni già note. Produce e traduce documentazione: gran parte del materiale Zope e Plone è in inglese, e una localizzazione fatta bene abbassa la barriera per amministrazioni e piccole realtà. E dà una voce collettiva verso la comunità internazionale, che per uno stack di origine europea come Plone conta eccome.

L’aspetto formale dell’associazione qui non mi interessa. Mi interessa che ci sia un posto dove un problema di risoluzione dei nomi per acquisition, o una strategia di conflict resolution su ZEO, si discutono tra persone raggiungibili nella stessa lingua e nello stesso fuso. Per uno stack di nicchia, è questo che separa l’adozione sostenibile dall’isolamento tecnico. Tra chi ha scelto di esserci dalla fondazione c’è anche noze, che su Zope/Python costruisce il proprio lavoro web e di content management: https://www.noze.it/insights/azi-fondazione/.

Limiti

Resta da vedere se il coordinamento terrà il passo della frattura Zope 2 / Zope 3, che nei prossimi anni imporrà scelte tutt’altro che banali. E un’associazione di utenti non rimpiazza il contributo di codice a monte: il valore di una comunità locale si misura anche da quante patch e segnalazioni rimanda alle linee di sviluppo internazionali, non solo da quanto consuma. Su questo si potrà dare un giudizio tra qualche riunione.

Immagine di copertina: Logo di Plone, sistema di content management open source basato su Zope — logo di The Plone Foundation, pubblico dominio — https://commons.wikimedia.org/wiki/File:Plone-logo.svg