Quale strumento per costruire il nostro CMS? Django vs. Plone

7 gennaio 2010

Da qualche anno Plone è il fulcro del mio lavoro quotidiano, e da qualche tempo sono in incursione nel mondo di Django sulla scia del successo che sta ottenendo.

Django (http://www.djangoproject.com/) è un web framework scritto in Python nato nel 2005 dal team di sviluppo web di una compagnia editoriale del Kansas, che ha accettato le richieste dei suoi tecnici di rilasciare le loro librerie con licenza open source.

Python (http://python.org) offre moltissime librerie per lo sviluppo di applicazioni web, e in tale categoria Django si è conquistato una sua posizione di eccellenza. Tuttavia, da plonista incallito, non mi era semplice comprenderne i motivi e le prerogative.
Per questo nelle ultime settimane ho iniziato a dedicare ritagli di tempo allo studio di Django e del suo ecosistema.

In questo post annoto una serie di considerazioni da usare in ordine sparso, confrontando Plone con Django da vari punti di vista, e spesso dicendo cose ovvie (o forse non troppo).

Prima cosa ovvia: confrontare Plone con Django non ha molto senso! 🙂

Plone (http://plone.org) è un Web CMS, con molte funzionalità avanzate e una pletora di prodotti aggiuntivi che ne estendono le possibilità di base.

Si rivolge in prima battuta a utenti “finali” che vogliono usare il CMS per gestire e pubblicare in rete i propri documenti e file, senza dover pasticciare con codice sorgente o file di configurazione, ne tanto meno con l’HTML delle pagine web.
Per questo da anni esiste un Installer con cui Plone viene rilasciato, che permette di installare quanto necessario in automatico, avviare il servizio e accedere al portale senza bisogno di essere tecnici esperti.

In ogni caso, configurare correttamente modifiche più o meno profonde richiede di studiare il framework, e servirà un po’ di esperienza.

Di fatto, la filosofia di base è tale che Plone può essere considerato un prodotto, un applicativo software che risolve una classe di problemi “out of the box”.

Django è invece un web framework! Parla la lingua dei programmatori, e dopo averlo installato non si ha nulla più di prima dal punto di vista dell’utente “finale” di cui sopra: fino a che non si inizia a mettere mano a del codice sorgente, scritto “rapidamente” quanto si vuole, nulla.

Nel seguito provo allora a spiegare i motivi di questo post.

Plone si è dimostrato negli anni un ottimo framework di sviluppo, supportato da un application server potente e flessibile quale Zope (http://zope2.zope.org), e da varie librerie al contorno longeve ed efficaci per la gestione dei workflow, la costruzione dei tipi di contenuto del portale e delle interfacce utente, la trasformazione dei contenuti, etc. etc.

Tutto questo, nel caso in cui si abbiano esigenze di gestione contenuti avanzate (come nel caso della redazione di un giornale online, o di un gestore documentale dipartimentale o di progetto) permette a mani esperte di raggiungere una soluzione robusta e versatile con poche ore di lavoro.

Django dal canto suo, per come sto imparando a conoscerlo, ha saputo sintetizzare e risolvere molto bene le problematiche di base delle applicazioni web (non necessariamente di quelle orientate ai contenuti) senza mettere in piedi un application server vero e proprio.

In Django, uno sviluppatore web per diventare produttivo ha bisogno di assimilare pochi semplici concetti ed alcune convenzioni. Tutto il resto potrà essere assimilato all’occorrenza, andando quanto più possibile direttamente al punto.

Tra i concetti fondamentali da acquisire:

  • la programmazione dell’applicazione è orientata al modello MVC (http://it.wikipedia.org/wiki/Model-View-Controller),
  • si dispone di un ORM specializzato che astrae la comunicazione col DB relazionale,
  • l’accesso alle viste (e quindi alle interfacce utente) è regolato da un sistema di URL dispatching (una lista di espressioni regolari associate a *funzioni* python responsabili di produrre le risposte richieste).

E fino a qui, non si vedono ancora i punti di contatto con Plone.. sebbene dal punto di vista di chi costruisce applicazioni web generiche l’appeal sia già evidente 🙂

Tale tassello mancante è legato al sacro graal al centro del mio post: l’esigenza che hanno alcuni di risolvere rapidamente esigenze mirate alla gestione dei contenuti ma senza il potere o volere di scomodare la “portaerei corazzata” Plone.

Django viene rilasciato con un’interfaccia di amministrazione web efficace e intuitiva, con cui accedere ai dati gestiti dalle applicazioni. In prima battuta tale interfaccia è sostanzialmente idonea a funzionare come sistema “embrionale” di gestione contenuti. A questo si unisce la lunghissima lista di applicazioni Django open source che possono essere adottate per completare le proprie esigenze.

Insomma, se devi andare in guerra pronto a battaglie campali, partire con una portaerei già armata come Plone è sicuramente un vantaggio, a patto di essere capaci di pilotarla e adattarla alle proprie esigenze. Ma se si volesse solo uscire in mare per una rapida battuta di pesca, e fino a ieri si era abituati al pattìno e alla lenza, costruire il proprio peschereccio piuttosto che imparare a pilotare la portaerei potrebbe essere preferibile.

Chiaramente la similitudine è forzata, ma rende l’idea che mi sto facendo durante questo viaggio nel mondo Django.

Uno dei tratti comuni a Plone e Django, dal punto di vista del “configuratore” è l’astrazione dello storage: la fase di memorizzazione e recupero dei dati dal proprio database è quasi trasparente per chi implementa l’applicazione. In Plone questo è garantito da Zope e dal suo DB a oggetti (ZODB: http://pypi.python.org/pypi/ZODB3/), Django invece dispone di un ORM (http://docs.djangoproject.com/en/dev/topics/db/queries) capace di astrarre tutte le logiche di lettura/scrittura verso il DB relazionale di volta in volta adottato (http://docs.djangoproject.com/en/1.1/ref/databases/).

Altro tratto in comune è la gestione dei template mediante un linguaggio che spinge le logiche applicative fuori dalle interfacce utente. Plone adotta fin dal suo esordio ZPT (http://pypi.python.org/pypi/zope.pagetemplate), una delle cui caratteristiche consiste proprio nel rendere la vita molto difficile a chi è abituato ad infilare nell’interfaccia utente le logiche applicative.

Allo stesso modo Django adotta un suo linguaggio di template che a differenza di ZPT è adatto a generare XML ma anche qualsiasi tipo di formato basato su testo. Inoltre il Django Template Language permette con facilità di creare i propri tag: è utile? non lo so ancora 🙂

Come accennato prima, l’accesso alle “viste” è risolto in maniera molto diversa dai due framework. Django utilizza una lista di patterns per determinare quale codice python dovrà gestire una richiesta. Questo lo rende semplice da imparare ed efficiente nell’implementazione.

Plone, d’altro canto, affronta la questione in maniera molto diversa. Le url vengono interpretate percorrendo il database ad oggetti, e l’ultima parte della url rappresenta la vista desiderata su quell’oggetto. Qui si incontra una stratificazione di implementazioni successive nel mondo Plone. Si possono avere due tipi di viste: le skin del CMF o le Browser View di Zope 3.

Gli skin CMF sono insiemi di oggetti (template, script, immagini etc) che servono a pubblicare le risorse conservate nel database a oggetti. Tra i loro svantaggi condividono uno stesso namespace e non c’è modo di customizzarle solo per un certo tipo di oggetti. Le Browser View sono molto più flessibili: il pezzo di codice che soddisferà la richiesta dell’utente viene scelto in base al tipo di oggetto e il tipo di richiesta, grazie alla ZCA.

Per la gestione dei content type Django è piuttosto embrionale, o meglio assente. Al contrario Plone dispone di un collaudatissimo framework chiamato Archetypes, che per quanto potente sta per cedere il passo al più giovane, ma non meno potente Dexterity. In entrambi i casi, definire un nuovo tipo di contenuto (edificabile via web con tutti i metadati Dublin core, ricercabile nel motore di ricerca interno, gestibile mediante il motore di workflow, etc.) è semplice come descriverne il suo schema degli attributi: a tutti i dettagli implementativi pensa il framework.

Dove Plone perde?

E’ decisamente più lungo diventare autonomi nel progettare e implementare applicazioni basate su Plone; ci sono molti più strati sedimentati nel corso di lunghi anni, che rendono l’acquisizione dello strumento Plone ancora più “ardua”; l’application server Zope è decisamente più oneroso nella sua gestione dello script che avvia il semplice server di sviluppo Django.

Questo si traduce anche in costi di gestione (server) più bassi per Django, dato che Plone è molto più esoso di memoria e cpu.

Dove Plone vince?

Gli stessi punti espressi nel paragrafo precedente, nel caso in cui si abbia bisogno di un’applicazione web di gestione contenuti avanzata, con un paradigma di sicurezza flessibile e robusto. Di fatto dover imparare di più coincide con un maggior numero di possibilità già presenti che non dovremo sviluppare per conto nostro.

Da non dimenticare: la Zope Component Architecture. Plone dalla versione 2.5 utilizza a piene mani la ZCA, e questo lo rende un sistema facilmente ed efficacemente estensibile, senza pagare pegno alla programmazione a oggetti o creare spaghetti software.

In una prossima puntata cercherò di parlarvi ancora di cosa si fa di interessante con Django.

Annunci

4 Risposte to “Quale strumento per costruire il nostro CMS? Django vs. Plone”

  1. Massimo Says:

    gran bell’articolo.

  2. miziodel Says:

    una cosa che avevo molto inaccuratamente dimenticato.. prima di pubblicare l’articolo ho chiesto l’appoggio di Silvio e Giorgio a sostegno di quel che stavo “blaterando”.. e loro me lo hanno dato..

    se vi sbrigate ne trovate anche la prova 😀
    http://piratepad.net/django-plone

    PS: piratepad e’ un ottimo servizio, basato sul neo-OS etherpad.. provatelo!

  3. Vito Says:

    Ben fatto Mizio! 🙂

    Ti dirò, io sto cercando di imparare qualcos’altro rispetto a Plone, così per guardarmi un po’ attorno. Col Plone mi trovo benissimo, ma suppongo che nel nostro mestiere “chi si ferma è perduto”.

    Ero indeciso tra tante tecnologie, molto diverse tra loro e non so bene cosa voglio… Pensavo a Django, RubyOnRails, Drupal e Adobe Flex…

    • miziodel Says:

      uhm.. Vito, credo sia piuttosto fondamentale per te capire cosa cerchi, altrimenti in mezzo alla miriade di strumenti oggi a disposizione (nessuno dei quali secondo me perfetto a risolvere completamente il “problema web”) non saprei veramente come orientarmi nemmeno io..

      per quanto mi riguarda ho le idee abbastanza chiare, e per questo continuo a ispezionare il mondo python e le sue moltissime possibilità. 🙂


Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: