Breve storia della tecnologia Plone

ovvero: perchè per modificare Plone e le sue funzionalità non esiste un unico, semplice modo?

Tenere corsi a chi un'idea di Plone ce l'ha già fa parte del mio lavoro, e spesso mi pongono la domanda:

"ma perchè in Plone ho tutti questi modi per fare anche le cose più semplici?!"

Dove ci si riferisce di solito ai mille meccanismi concorrenti attivati per costruire la "semplice" pagina di Plone.. e portal_skin, e i template zpt, e la "custom", e il portal_css, e le portal_actions, e le portlet, e le viewlet, e ...

La mia risposta è un percorso "storiografico" per chiarire da dove viene Plone.

[NB: non me ne vogliano i conoscitori di quel che vado a raccontare per le eventuali imprecisioni ed esemplificazioni, se trovano che il senso resta valido..]

In principio era Zope

... e Jim Fulton vide che era cosa buona e giusta, e con lui quelli di Digital Creations, Paul Everitt in testa, che decisero di offrire questa tecnologia al mondo con licenza aperta.

1998: Zope era una fiaccola nel buio degli anni in cui un application server non si sapeva cosa fosse, e quelli bravi in ambito open andavano di Perl e CGI.

Zope proponeva un suo paradigma di sviluppo (Python, programmazione a oggetti , ..), ma anche una sua prospettiva originale sull'applicazione web ante-2000: al centro metteva la visione del web a oggetti, che ruotava intorno ad alcune eleganti tecnologie ancor oggi esistenti nel bene (ZODB ..) e nel male (Acquisizione ..).

Zope era una bomba, e permetteva di creare applicazioni web avanzate nel giro di giorni, quando i suoi "concorrenti" richiedevano settimane o mesi..

MA, c'era una ma: dovevi capire come usarlo.

Quindi fu Zope 2

... e Digital Creations vide che la comunità open source era cosa buona e giusta, e decise di favorirla creando con Zope un nuovo modo di costruire applicazioni web: attraverso il web (TTW)!

2000: con Zope 2 si dispone di un'applicazione web per costruire l'applicazione web, e si possono generare potenti applicativi senza installare tool di sviluppo sulla propria macchina.

Zope 2 promuove un paradigma misto di sviluppo, in cui programmazione classica si mescola a un modo "atipico" di costruire l'applicazione web, mediante "oggetti" istanziati direttamente tramite il browser web: alcune cose erano buone (ZMI ..) e altre non lo erano affatto (ZClass ..).

Zope 2 era una bomba, e consentiva anche a chi programmatore non era di creare applicazioni web potentissime nel giro di giorni, quando la concorrenza.. va be', lasciamo stare :)

MA, c'era un ma: dovevi capire come incastrare tra loro tutti quegli oggetti creati via web.

E vennero i Portali

... e gli ingegneri di Digital Creations videro che erano cosa buona e giusta, e ne distillarono i pattern principali nel Portal Toolkit, oggi meglio noto come CMF.

2001: il CMF (Content Management Framework) anticipa buona parte dei suoi potenziali concorrenti a licenza chiusa, figuriamoci in ambito aperto. :)

Con CMF viene offerta una risposta alla richiesta di portali, ma si cerca anche di "correggere" alcune delle promesse di Zope che si erano trasformate in "incubi": acquisizione, zclass, sviluppo via web sono concetti affascinanti ma presto dimostratisi impraticabili. Inoltre si introducono nuove possibilità, nate per restare (portal_types, portal_skins, portal_workflow, ..).

CMF è una bomba, e il suo detonatore e' CMF Default, un portale pronto all'uso offerto in open source per mostrare le potenzialità di CMF, e tale da poter essere utilizzato in produzione.

MA, c'era un ma: dovevi capire il modello del CMF, e come si utilizzano i suoi tool.

Finalmente nasce Plone

2002: Plone è una skin nanerottola sulle spalle del gigante CMF Default, ottimo dal punto di vista funzionale, ma completamente inadeguato dal punto di vista dell'usabilità,

Nel corso degli anni Plone ottiene un successo strepitoso, attirando una corposa comunità, e oggi è di fatto l'unico utilizzatore forte di Zope 2. Chiaramente Plone ha fatto crescere CMF, aggiungendo funzionalità fondamentali (Archetypes su tutte), ma anche tentando strade ritenute in seguito non sostenibili (KSS ..).

Plone si dimostra presto una soluzione open source ideale per costruire portali aziendali, intranet, sistemi documentali collaborativi, e penetra in migliaia di contesti diversi con le sue varie versioni.

MA, c'è un ma: Plone mescola la semplicità delle funzionalità offerte all'utente finale al fatto che, per padroneggiarlo, devi comprendere lo stack su cui è costruito: Zope, Zope 2 e CMF.

Tempo di cambiamento: Zope 3

2002: manipolare la complessa gerarchia di oggetti alla base di Zope per ottenere comportamenti diversi da quelli previsti è molto difficile.

Dopo alcuni anni di vita sul campo, Jim Fulton aveva intuito che Zope 2 era chiuso in una gabbia che non gli avrebbe permesso di continuare a volare.

La soluzione proposta per superare questa condizione introduce lo sviluppo a componenti, e la sua realizzazione passa dalla Zope Component Architecture (ZCA), che Jim Fulton realizza rifondando il progetto Zope e facendo leva su una comunità aperta di sviluppatori (Zope Corporation decise di restare ai margini).

Il nome Zope 3 comportò non poca confusione nei suoi neofiti, dato che in comune con Zope 2 aveva molto poco:

un'applicazione Zope 2 pura non poteva girare in Zope 3 e viceversa!

2005: nasce Five, una libreria di raccordo che consente di utilizzare la tecnologia di Zope 3 nelle applicazioni basate su Zope 2.

Dal 2006, Plone ottiene vantaggi enormi dall'uso della tecnologia dei componenti: maggiori funzionalità, efficienza, configurabilità, ...

MA, c'e' un ma: mantenere continuità con le precedenti versioni e approfittare della potenza derivante dai componenti di Zope 3 comporta il moltiplicarsi dei possibili modi di fare le cose.

Ricapitolando: Plone per un neofita del 2011

Plone è figlio di un'evoluzione che dura da oltre dieci anni, senza soluzione di continuità.

L'architettura del Plone di oggi è basata su tre diversi modi di concepire e fare sviluppo web:

  • Zope 2, lo storico application server (per ora imprescindibile),
  • CMF, la longeva libreria su cui Plone basa le sue fondamenta di portale
  • Zope 3 (oggi noto come Zope Toolkit), fondato sulla tecnologia dei componenti, e capace di competere con i migliori framework web attuali.

Dal mio punto di vista, la comunità Plone ha sempre tutelato due principi saldi e fondamentali:

  • non tradire i vecchi sviluppatori e le vecchie versioni, garantendo la retro-compatibilità al massimo possibile
  • seguire l'evoluzione del mondo Zope, non restando ancorati a schemi del passato

Dalla versione 2.5 lo sviluppo Plone avviene quasi completamente adottando tecnologie Zope 3, al prezzo di una apparente maggiore complessità di sviluppo. In realtà, tale complessità è spesso confusa in mezzo ai tanti modi di fare le cose derivanti dalla storia che vi ho raccontato.

Ecco questa è la mia sensazione:

in un momento non troppo lontano, Plone non avrà più bisogno di Zope 2.

I segnali ci sono da tempo (lo sapevate che Plone 5 reinventerà il modo di usare Plone da parte dell'utente finale? :))

Come superare il guado?

Normalmente chi incontra Plone senza avere tempo e modo di entrare nei meandri dello stack nella sua interezza fa molta fatica a trovare soluzioni alle prime difficoltà.

Come fare? Procuratevi un buon libro, imparate a usare tutta la documentazione esistente (facendo attenzione a quella obsoleta), affidatevi a qualcuno che dimostri di padroneggiarlo adeguatamente (nelle chat, nelle mailinglist, agli incontri).

In ogni caso, conoscere come è costruito Plone è propedeutico a poterlo padroneggiare nel momento in cui dobbiamo piegarlo alle nostre esigenze, altrimenti il rischio di maledirlo è (come è sempre stato) molto grande.

Come diceva Miyagi:

"Quando cammini su strada, se cammini su destra va bene.
Se cammini su sinistra, va bene.
Se cammini nel mezzo, prima o poi rimani schiacciato come grappolo d'uva.
Ecco,
Karate è stessa cosa.
Se tu impari Karate va bene.
se
non impari Karate va bene.
Se tu impari
Karate-Speriamo, ti schiacciano come uva"

Traduco: se non hai il tempo/modo di imparare, cerca di modificare i funzionamenti di Plone il meno possibile, passando dal pannello di controllo quando si può, o installando prodotti aggiuntivi riconosciuti come "validi" dalla comunità.

Domanda delle cento pistole: esiste un modo "buono" di fare le cose?

Ne esistono due.

Il primo è quello di chi conosce Plone e i suoi meccanismi, e sceglie di volta in volta la strada che fa più al caso suo.

Il secondo è quello "giusto", dettato dalla comunità Plone (che non si muove per dictat, ma per proposte accettate e implementate). Come si riconosce questo modo? Basta guardare come Plone viene sviluppato con occhi sufficientemente preparati.

NB: esiste un terzo modo, che consiste nel prendere la prima strada che sembra risolvere la richiesta, pronti poi a lanciare maledizioni nel caso si riveli la scelta sbagliata.

Share this on

Share |

On same topics

Commenti

comments powered by Disqus