Nelle ultime settimane sono stati rilasciati un paio di prodotti molto interessanti, che possiamo facilmente abbinare per gestire situazioni in cui un unico portale Plone viene usato per centralizzare la gestione di contenuti che poi devono essere pubblicati separatamente.

Questo si poteva fare già da tempo, ma non con tale facilità e pulizia concettuale.

NB: i due prodotti sono perfettamente validi anche se non li usiamo in coppia!!

Calvin Hendrix-Parker ha pubblicato collective.lineage (http://plone.org/products/collective-lineage) con lo scopo di permettere la generazione di aree Plone che si comportano come mini-siti. Ma cosa significa? semplicemente che, quando si accede ad un'area del genere, tutta la navigazione del portale viene centrata su quell'area.

Plone con Lineage installato (ingrandisci)

Come si vede nello screenshot, il portale Plone dispone di un nuovo content type, Child Folder, che dobbiamo creare in corrispondenza delle aree da ripubblicare autonomamente.

Per provare come funziona, ho creato un paio di Child Folder con i nomi Dipartimento X e Dipartimento Y. Accedendo al primo dei due, quello che si ottiene è visibile nel secondo screenshot:

Il mini-sito del Dipartimento X (ingrandisci)

La navigazione è centrata sul nodo selezionato: cliccando sul tab "portale" o sul logo si viene portati all'URL corrispondente al Child Folder visitato, i portal tabs sono costruiti con gli elementi di primo livello del nodo selezionato, come pure i breadcrumbs. Insomma, si ha la sensazione che il portale sia solo questo!

Per tornare rapidamente alla radice del sito Plone, Lineage offre un selettore in alto a destra, tramite cui potremo accedere anche ad uno qualsiasi dei mini-siti che avremo definito.

Questa architettura può risultare molto comoda in tutti quei casi in cui oggi siamo costretti a creare una serie di siti Plone e a gestire separatamente utenti, skin, workflow, e tutto il resto, quando invece si desidera solo che i singoli utenti possano vedere la propria fetta di portale come centro del loro universo Plone. Penso ai cosiddetti siti dipartimentali, come nel caso di un'azienda e delle sue filiali, o di un'università e delle sue facoltà.

Installare Lineage è un gioco da ragazzi, con buildout, ma tenete presente che per poter funzionare in modo coerente, Calvin ha dovuto richiedere una Plone Improvement Proposal, la 234, che sarà integrata in Plone solo dalla versione 3.3. Quindi, occhio al suo readme: http://plone.org/products/collective-lineage!!

Veniamo a collective.skinny (http://plone.org/products/collective-skinny), proposto da Daniel Nouri, e cerchiamo di capire in quale contesto si cala. Da qualche anno Plone ha rivoluzionato il mondo dei CMS immergendo le funzioni di gestione nel contesto usato per la pubblicazione dei contenuti. La cosa non è banale, in quanto semplifica la vita di chi gestisce i contenuti in modo notevole, e non solo dal punto di vista dell'usabilità dello strumento.

Questo comporta molto vantaggi, ma anche qualche difficoltà, in particolare quando, piuttosto, si ha bisogno della separazione tra le funzioni di gestione e di pubblicazione, o quando si deve costruire una skin complessa per i soli utenti lettori.

Bene, esistono varie possibilità per ottenere questa separazione: Deliverance e ContentMirror solo per citare quelli che io preferisco. Tuttavia per qualche strano motivo, tutti continuavano a guardare il dito che nascondeva la luna.. e la luna?

La luna è Zope, e Daniel ha avuto l'ingenuità e il coraggio di tornare a metterlo al centro del discorso, scoprendo che vari altri zopisti avevano ben chiara tale possibilità, ma nessuno osava "pubblicizzarla".

Skinny non fa altro che questo: costruisce un layer Zope 3 e definisce su tale layer una nuova skin per Plone, basata su Browser View che ricostruiscono da zero l'interfaccia utente da applicare a Plone.

Al di là del fatto che "mi piace!", volete sapere cosa ho fatto? Ho provato la strada proposta da Daniel, applicandola a un Child Folder di Lineage.

Nel giro di mezz'ora ho scaricato un tema per Wordpress, "White as Milk" (http://www.azeemazeez.com/blogs/white-as-milk/), e ho provato ad applicarlo al mio Plone direttamente modificando Skinny. Tempo impiegato: 30 minuti scarsi.

Poi ho seguito le indicazioni di Daniel per raggiungere il mini-sito del Dipartimento X con una rewrite rule nel web server, e il risultato è stato quello che vedete nello screenshot :D

dipartimento X con skinny W.a.M. (ingrandisci)

Potete immaginare come questa skin sia molto limitata rispetto a quella base di Plone, d'accordo... Inoltre ci sono ancora una serie di problematiche aperte, ma siamo solo alla versione 0.3, e, se piace alla comunità, sicuramente il prodotto sarà molto evoluto nel giro di pochi mesi. Ad esempio saranno meglio gestiti i "leakage" verso parti del portale che non dovrebbero essere raggiunte se skinny è in azione, pena il "ritorno" allo skin di base di Plone; come pure sarà certamente disponibile in ZopeSkel un template per creare tutte le "skinny" che ci servono, e non limitarci all'unica che possiamo installare nell'istanza Zope.

Di fatto, eccovi un po' di numeri. Lanciando il comando ab sia sulla versione originale che su quella "skinny" che vedete nelle due screenshot del Dipartimento X, vi presento i risultati.

Nel caso standard ho ottenuto:

$ ab -c3 -n 100 http://127.0.0.1:8080/lineage/dipartimento-x

Benchmarking 127.0.0.1 (be patient).....done

Server Software:        Zope/(Zope
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /lineage/dipartimento-x
Document Length:        12729 bytes

Concurrency Level:      3
Time taken for tests:   14.860 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1301000 bytes
HTML transferred:       1272900 bytes
Requests per second:    6.73 [#/sec] (mean)
Time per request:       445.799 [ms] (mean)
Time per request:       148.600 [ms] (mean, across all concurrent requests)
Transfer rate:          85.50 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:   218  444 105.0    435     745
Waiting:      182  429 106.0    421     745
Total:        219  444 105.0    435     746

Percentage of the requests served within a certain time (ms)
  50%    435
  66%    472
  75%    514
  80%    533
  90%    612
  95%    655
  98%    700
  99%    746
 100%    746 (longest request)

Passando da Skinny, invece:

$ ab -c3 -n 100 http://localdipx/

Benchmarking localdipx (be patient).....done

Server Software:        nginx/0.6.35
Server Hostname:        localdipx
Server Port:            80

Document Path:          /
Document Length:        3361 bytes

Concurrency Level:      3
Time taken for tests:   4.882 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      352000 bytes
HTML transferred:       336100 bytes
Requests per second:    20.48 [#/sec] (mean)
Time per request:       146.469 [ms] (mean)
Time per request:       48.823 [ms] (mean, across all concurrent requests)
Transfer rate:          70.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       5
Processing:    55  145  39.1    141     268
Waiting:       55  145  38.9    141     268
Total:         60  146  38.9    141     268

Percentage of the requests served within a certain time (ms)
  50%    141
  66%    157
  75%    163
  80%    173
  90%    199
  95%    219
  98%    255
  99%    268
 100%    268 (longest request)

Non può non saltare all'occhio uno dei dati fondamentali: Plone base serve in media 6 richieste/sec, mentre a parità di condizioni, con la versione Skinny ottenuto 20 richieste/sec, e senza nessun tipo di ottimizzazione!