Carmine Noviello

Alzi la mano chi almeno una volta non ha pensato che Zope non è un framework per lo sviluppo rapido di applicazioni web. E a giudicare dalla proliferazione di prodotti concorrenti (Django, Pylons, Turbogears, ecc), e il loro relativo successo, vuol dire che a fare questa considerazione devono essere stati in molti.

Purtroppo questa nomea è ormai ampiamente diffusa, al punto che anche ai vertici della comunità si stanno ponendo già da tempo il problema di come rilanciare il prodotto, sia per quanto riguarda Zope sia la sua applicazione più diffusa: Plone. Già, perché forse quest’ultimo prodotto è in gran parte responsabile di questa reputazione, essendo molto più popolare del framework stesso e ed essendo la porta che apre effettivamente la strada al mondo Zope.

Ma qual è l’origine di tutto ciò? Chi conosce Zope e ci lavora da tempo (il sottoscritto da oltre 5 anni) è ampiamente a conoscenza delle vicissitudini del framework, ma proverò qui a sintetizzare i punti più critici.

• Zope 2: il problema principale di Zope è stato, e rimane, Zope 2. Ebbene, la versione che ha reso celebre Zope è anche quella che ha sensibilmente contribuito al declino della piattaforma. Un modello di programmazione monolitico, un ciclo di sviluppo troppo pressante che spesso e volentieri ha portato all’insorgenza di pesanti incompatibilità tra una minor revision number ed un’altra hanno fatto sì che Zope si è conquistato l’appellativo di framework poco pythonico. Ed è vero. In Zope 2 per sfruttare una singola funzionalità eri costretto ad adoperare contemporaneamente l’intero framework, o poco ci mancava, con pesanti ripercussioni sulla velocità di sviluppo, la stabilità e longevità del codice, la curva di apprendimento (forse Zope è uno dei pochi strumenti che controbilancia la curva di apprendimento di Python che è molto bassa).
• Zope 2 + 3: quando la comunità ha capito che quel modello di programmazione, basato su un uso abnorme di ereditarietà e mix-in programming, non avrebbe fatto molta strada, ha cominciato a sviluppare un framework basandolo su un modello di programmazione radicalmente diverso, ossia quello per componenti. Lo sviluppo di Zope 3 risale a molti anni addietro, ma la sua diffusione si è andata consolidando soltanto di recente e soprattutto quando la comunità si è resa conto che senza una smooth transition nessuno sarebbe mai passato al nuovo mondo. Per questo, si è cominciato ad importare quel modello di programmazione, e le componenti già sviluppate per Zope 3, in Zope 2, con l’ausilio di Five. Da quel momento in poi c’è stata una sorta di frattura che ha generato solo caos, a mio modo di vedere. Si è assistito (e lo si vede ancora oggi) a prodotti che presentavano un approccio misto, con codice per metà a componenti e per metà alla vecchia maniera. Inoltre, si è imposto a tutti quelli che seguivano il prodotto un passaggio ad un nuovo modello di sviluppo senza che se ne capisse veramente l’utilità e soprattutto dovendolo far convivere con altro codice che costantemente violava i dettami della programmazione per componenti. Plone, è l’esempio più lampante di questo, e ancora più emblematiche sono le liste dei requisiti di Plone 3.x e 4.x che sono state costantemente modificate nel tempo spostando in avanti passaggi critici per la migrazione a Zope 3.
• Plone: quando si parla di Zope è inevitabile accostarlo a Plone, che è sicuramente il prodotto più diffuso della piattaforma. Ebbene, Plone è uno dei principali responsabili del degrado dell’immagine complessiva di Zope. Anche lui, infatti, presenta delle complessità connesse sia sul fronte del progetto complessivo sia per quanto riguarda il target stesso del progetto. Innanzitutto Plone è un CMS, e in quanto tale si è evoluto. Questo ha comportato che col tempo il prodotto si è andato arricchendo di funzionalità che lo hanno da un lato reso forse uno dei migliori CMS disponibili, dall’altro hanno indebolito il fronte della versatilità e velocità di sviluppo. Se con Plone 2.0 era ancora pensabile sviluppare siti web leggeri e "agili", oggi è diventato sempre più impensabile adoperarlo in questi ambiti sia perché richiede tempi di sviluppo ed adattamento notevoli, sia perché impone all’utente finale conoscenze non del tutto di base. Per quanto riguarda lo sviluppo, anche con Plone si è assistito ad un costante cambiamento che ne ha minato la stabilità. Ancora oggi si assiste ad una serie di contraddizioni che sono difficili da comprendere: si è ormai abbracciata in molti aspetti la filosofia di sviluppo di Zope 3, ma si continua a presentare gli Archetype come la libreria di base per estendere il set dei content-type.
• Zope 3: lo stesso Zope 3, nato per garantire un futuro solido alla piattaforma, ha contribuito al suo indebolimento. Innanzitutto, il modello di programmazione per componenti è di difficile digestione alla massa dei programmatori python e soprattutto richiede delle esigenze forti per essere adoperato. Se per un framework come Zope può rappresentare la soluzione migliore per migliorare la modularità e il riuso del codice (è una possibile soluzione, ma bisogna ammettere che non è necessariamente l’unica in un linguaggio che promuove il duck typing), per un’applicazione tipo e di dimensione limitata, pensare per componenti può essere una forzatura, e spesso aumenta la complessità del codice senza benefici tangibili. Poi, Zope 3 ha introdotto dei cambiamenti che hanno sensibilmente stravolto l’idea di Zope. Ad esempio, lo sviluppo TTW è stato ufficialmente bandito (indubbiamente ottima scelta), ma non c’è dubbio che la ZMI è stata una delle parti che ha maggiormente contribuito alla diffusione di Zope 2. Infine, la voglia di modularizzare al massimo ha spinto fin alla modularizzazione e parametrizzazione della fase di configurazione del framework, con l’introduzione dello ZCML che ha ulteriormente complicato la vita del programmatore medio e molto indaffarato.
• ZODB: l’ultimo della carrellata (ma non sicuramente per importanza ai fini di questa analisi, anzi…..) è il database ad oggetti di Zope. Innanzitutto, far capire ad un cliente che non si ha un database relazionale come Oracle o MySQL è un’operazione di una difficoltà inaudita, e spesso il cliente preferisce ricorrere ad altre soluzioni ma non rinunciare al DBMS. Le ragioni di ciò sono complesse, ed esulano dallo scopo di questo mio post, ma va detto che per molti aspetti i DBMS relazionali classici continuano ad offrire versatilità, scalabilità e fruibilità maggiore. Poi ci si è aggiunta la nomea che lo ZODB è scarsamente performante. In realtà, non è così. Soprattutto dalle versioni 3.6 e successive, lo ZODB è diventato estremamente veloce e affidabile (transazionale, ecc). Quello che continua ad essere scarsamente performante è il software che lo usa, e spesso stiamo parlando di Plone che per mia esperienza rimane un prodotto molto pesante ed assetato di risorse hardware (sul circuito campaniabeniculturali.it che ospita nodi da 63 portali Octapy, che sono basati su Plone, abbiamo server da 12 o più GB di RAM che soffrono non poco).

Dopo tutto questo sproloquio, può Zope 3 essere ancora considerato un valido prodotto per lo sviluppo di applicazioni web? Secondo me si, soprattutto perché parliamo di un framework maturo, stabile, e che oggi fornisce decine di componenti per le più disparate necessità (gestione form, sessioni, database, autenticazione, permessi, workflow, AJAX, REST, i18n, indicizazzione e ricerca, cache, testing) che altri framework non possono neanche lontanamente pensare di fornire. Come sfruttare al meglio tutto ciò?

Grok è il prodotto della comunità Zope nato per ridurre sensibilmente il ciclo di sviluppo di un’applicazione Zope 3. L’idea alla base di Grok è quella di riportare la piattaforma su un livello di programmazione agile e al tempo stesso intuitivo per il programmatore, senza sacrificare i dettami della component architecture. Grok introduce la nozione di direttive per indicare al framework quali caratteristiche una determinata componente deve avere: quella direttiva sarà espansa in istruzioni ZCML in maniera automatica senza che il programmatore deve impelagarsi in aspetti di configurazione delle componenti.
Dopo anni di sviluppo Zope 2/3 devo dire che Grok è un prodotto molto eccitante. Si riesce veramente a sfruttare al pieno la piattaforma senza doversi sobbarcare molti degli aspetti che l’hanno resa ostica. Tanto per far capire, vi faccio un esempio rapido di una semplice applicazione Grok.
 

1
2
3
4
5
6
7
8

import grok
 
class App(grok.Container, grok.Application):
    pass
 
class Index(grok.View):
    def reder(self):
        return &quot;<h1>Hello World!</h1>&quot;

Il codice per molti sarà estremamente chiaro: si crea la classe che rappresenta l’intera applicazione (App) che sarà automaticamente instanziata dal framework all’atto del caricamento, e la vista di default dell’applicazione (View) che restituisce la stringa HTML "<h1>Hello World!</h1>".

Ovviamente questo frammento di codice non è sufficiente a far capire né quanto Grok possa semplificare la vita né quanto Zope 3 sia completo e potente, ma chi conosce un po’ di Zope non può non ammettere che siamo alla presenza di un sensibile passo in avanti.

Continuerò a presentare Grok sul mio blog, con tutorial più completi e casi concreti, perché credo seriamente che Grok sia il futuro della piattaforma Zope 3, o se non altro contribuirà al suo sviluppo. Nel frattempo non posso fare altri che rimandarvi al PyCon Tre, nel quale terrò un talk introduttivo su Grok con Francesco Merlo. Ci vediamo a Firenze!

Be Sociable, Share!

•