Per chiarire cosa sia il front-end development si potrebbe usare una metafora automobilistica (come nella migliore tradizione dei venditori): costruire una web app è come costruire una macchina, il front-end developer è chi si occupa di montare i sedili in pelle, le finiture in radica, il volante, i pedali ecc., mentre il back-end developer è chi si occupa di montare il motore, i freni e la trasmissione. Quindi il front-end development è tutta la parte di sviluppo che, una volta piazzati i componenti strutturali, si occupa di rendere il prodotto davvero utilizzabile e più confortevole.

Il front-end development coinvolge principalmente 3 tecnologie: html, css e javascript. Negli anni queste tre tecnologie hanno mostrato i loro difetti: l'html e il javascript sono vecchi e "brutti" e, anche se il css non è brutto di per sé, è totalmente anti-DRY (don't repeat yourself!). Per contro, il web di oggi impone design ogni giorno più complessi e richiede la compatibilità non solo con tutti i possibili browser, ma anche con un numero sempre maggiore di dispositivi hardware come smartphone, tablet, desktop, ecc.

Per affrontare queste nuove sfide, il front-end design ha fatto balzi in avanti come pochi altri rami dell'informatica ed è nata una miriade di nuovi strumenti, come appunto i front-end framework. Oggi non si parla più solo di fogli di stile css "artigianali" e di qualche pezzo di codice javascript qua e là, ma di veri e propri framework per il design di user interface sempre più accattivanti.
Alcuni di questi framework si limitano a fornire le fondamenta, come ad esempio Skeleton, mentre altri arrivano a coprire ogni aspetto di un'interfaccia utente come ad esempio Bootstrap.

Pro e contro dei framework

Come sempre sulle scelte tecnologiche, sul web si aprono crociate e contro-crociate (certa gente ha troppo tempo libero) quindi ecco la mia personale e per niente esaustiva lista di pro e contro all'utilizzo dei front-end frameworks.

Contro:

• codice non scritto da noi, quindi bisogna imparare a conoscerlo
• rischio di design simili fra loro (ormai i siti "bootstrap" si riconoscono a colpo d'occhio)
• si rischia di aggiungere un nuovo livello di complessità e astrazione.

Pro:

• design più veloce e agile, non c'è bisogno di partire da zero
• la web app è già pronta per il mobile
• l'organizzazione dei file e del codice è ben studiata e "ingegnerizzata".

Frameworks a confronto

Dei tanti front-end framework disponibili ho deciso di portare i due esempi di maggior successo con due brevi schede tecniche: Bootstrap by Twitter e Foundation by Zurb.

Twitter Bootstrap

Sleek, intuitive, and powerful front-end framework for faster and easier web development.

- sviluppato da: Twitter
- primo rilascio: Agosto 2011
- licenza: Apache v2.0
- supportato da tutti i maggiori browser (IE>7)
- scritto in less (the dynamic stylesheet language)
- supporto al mobile: desktop, tablet e smartphone
- Il progetto più popolare su github.

Zurb Foundation

The most advanced responsive front-end framework in the world.

- sviluppato da: Zurb, azienda attiva nel web design
- primo rilascio: Settembre 2011
- licenza: MIT Licence
- scritto in sass
- 16esimo progetto più popolare su github
- supporto al mobile: desktop, tablet e smartphone.

Per un confronto più puntuale sulle caratteristiche, consiglio queste due ottime fonti:

• http://responsive.vermilion.com/compare.php
• http://usablica.github.io/front-end-frameworks/compare.html

And the winner is...?

Tra i tanti framework open source disponibili, la mia scelta è al momento per Twitter Bootstrap per l'eccellente qualità e la quantità di features, e secondariamente per un fenomeno detto esternalità di rete.

Integrazioni con Plone

Vediamo ora come la comunità Plone ha integrato questi front-end framework (per ora solo Bootstrap) nel nostro cms.

plonetheme.bootstrap:

Questo prodotto è un tema "vecchio stile" iniziato da Nathan van Gheem e Mikel Larreategi. L'approccio di questo tema è quello di riscrivere molti template di Plone per aderire alle specifiche di Bootstrap. L'effetto, come potete vedere dall'immagine, è notevole e l'integrazione è quasi perfetta. L'unico dubbio che rimane è sulla velocità di customizzazione di questa soluzione.

• http://pypi.python.org/pypi/plonetheme.bootstrap
• http://github.com/collective/plonetheme.bootstrap

diazotheme.bootstrap:

Un'altra ottima integrazione di Bootstrap in Plone è fatta da Izhar Firdaus di Inigo Consulting. Questo tema è basato sulla nuova tecnologia per la scrittura dei temi di Plone, cioè Diazo. L'integrazione del framework è per forza di cose meno spinta della soluzione precedente, ma l'effetto finale è comunque notevole. Al contrario del precedente tema, qui non ci sono dubbi sulla velocità di customizzazione che è sicuramente più agile.

• http://plone.org/products/diazotheme.bootstrap
• http://github.com/kagesenshi/diazotheme.bootstrap

"This is the end..." ♫

Hold your hats and stay tuned!

Nonostante il primo prodotto abbia un ottimo livello qualitativo, la mia scelta al momento va sul secondo per la maggiore agiltià e facilità di customizzazione. In ottica futura questa soluzione permetterà anche a designer agnostici di Plone di entrare nei progetti con pochissimo overhead e di trovarsi a loro agio con gli strumenti che già utilizzano (ad es. Node.js + Plone mockups + bootstrap). Ma di questo parleremo più approfonditamente nelle prossime puntate.

Poi, però, capita che un paio di giorni prima della scadenza (argomento già trattato da Ale in un post precedente) arrivi una richiesta di un cliente che mi accende la lampadina e mi da il LA per scrivere il mio prossimo articolo.

Il caso di studio che vi racconto è partito da una semplice richiesta:

Sarebbe possibile permettere agli utenti del sito di rimanere sempre aggiornati con i nuovi contenuti del sito?

Usiamo le contenrules! Un gioco da ragazzi!

Ma la domanda nascondeva qualche trabocchetto (o come direbbe Data, un tracobbetto): infatti gli "utenti" potevano anche essere utenti anonimi, e gli utenti stessi dovevano potersi iscrivere liberamente alle notifiche, senza passare per un gestore intermedio (ingenuamente mi ero illuso di poter creare un form di richiesta con Products.PloneFormGen in modo che poi i gestori potessero raccogliere le iscrizioni e gestire le liste di notifiche direttamente nella regola).

A questo punto, dopo alcune ricerche, era chiaro che nessuno dei prodotti disponibili faceva al caso mio.
Dovevo quindi studiare un modo per soddisfare questa richiesta e donare alla comunità un nuova utile funzionalità. Per questo è nato collective.contentrules.subscription.

E' un prodotto molto semplice che ha due componenti principali: una nuova azione per le regole e un tool che memorizza le varie sottoscrizioni.

Nell'azione da associare alle regole si possono inserire il soggetto e il testo della mail che verrà poi spedita, e quando viene scatenata questa azione, la lista di email a cui spedire la notifica è presa interrogando il tool e recuperando la lista di indirizzi a lei associata.

Lato utente, è presente una vista che mostra tutte le possibili regole disponibili (ovviamente solo quelle che hanno la nostra nuova azione impostata), da cui può scegliere a quali iscriversi. E' previsto anche un controllo di prevenzione per lo spam sfruttando collective.z3cform.norobots.

Esiste poi anche un pannello di controllo per i gestori del sito, che permette di avere una panoramica sullo stato delle iscrizioni ed eventualmente intervenire per rimuoverne.

Il tutto ovviamente è versionato e disponibile su github, quindi se vi piace l'idea e volete contribuire a migliorarlo, siete i benvenuti :)

Questa è una versione di partenza e mancano diverse funzionalità utili che potrebbero essere introdotte nelle prossime versioni, come per esempio la possibilità da parte degli utenti di visualizzare le proprie iscrizioni ed eventualmente cancellarsi, e anche un maggior livello di sicurezza nella gestione delle sottoscrizioni (ad esempio con un passaggio di validazione e conferma dell'indirizzo inserito).

Vediamo ora come affrontare i problemi restanti.

Fase 2: come trattare il pregresso

Infatti è solo ora che le cose si fanno interessanti...

Ci siamo trovati di fronte a un grosso problema: come "bonificare" la situazione creatasi negli anni precedenti alle modifiche sopra descritte?

Sarebbe stato possibile scrivere una procedura automatica che sistemasse automaticamente tutti i link generati tramite TinyMCE dalla forma canonica alla forma di download modificata?
La risposta per noi è stata "forse... ma meglio di no". Si parlava di centinaia (migliaia) di link, per decine di siti Plone.

L'eventualità di eseguire qualcosa senza un intervento umano era a dir poco terrificante, col rischio di trovare contenuti rovinati dall'operazione dopo mesi.
Molto meglio aiutare l'utente a sistemare il problema, cercando per lui i potenziali link da sistemare ma chiedendo conferma dell'operazione: un lavoro di certo più lungo ma che dà la sicurezza del risultato.

Il primo passo è stato quindi quello di riprendere uno spike, un prodotto mai rilasciato che si occupava di ricerca all'interno del testo Plone usando espressioni regolari, e renderlo qualcosa di utilizzabile da interfaccia Plone: rt.bulkmodify.

Il prodotto presenta un'interfaccia Plone che permette di cercare testo all'interno dei contenuti del sito. Quando il testo viene trovato, una tabella viene popolata con i risultati.

Visto che questo tipo di operazione richiede il risveglio dei contenuti Plone, il tempo richiesto per completarsi su un sito molto popolato potrebbe essere tanto lungo da mandare in timeout la richiesta, quindi la scelta presa è stata quella di fornire un'interfaccia JavaScript reattiva, completamente basata su chiamate AJAX.
Se tutta l'operazione dovesse durare anche 20 minuti, questa viene spezzata in tante piccole chiamate che terminano velocemente.

Oltre alla ricerca è poi possibile eseguire la sostituzione del testo trovato, sempre sfruttando le espressioni regolari.

C'è un problema: una semplice espressione regolare con sostituzione testuale non può sistemare il problema perché non c'è modo di sapere, senza un'analisi del contenuto Plone, il nome reale del file caricato.

Il prodotto doveva quindi essere estendibile, permettendo di lanciare speciali operazioni lato server di sostituzione del testo, per individuare i link interni ai file e trasformarli nella forma voluta. Tutto questo è stato di nuovo inserito nel prodotto specifico del Cliente ma senza tradire l'idea iniziale: sarà una persona in carne e ossa che supervisionerà e deciderà cosa sostituire e cosa no.

Link a file... esterni!

L'ultimo pezzo del puzzle riguarda i link tra siti diversi.
Il Cliente ha un grande numero di siti Plone che, per fortuna, condividono il 90% dei prodotti installati.

La necessità di sistemare le statistiche era quindi valida anche per link ad altri siti del Cliente.
Se quindi un sito nel dominio "http://sub1.vostro-host.com/" conteneva un link a un file in un altro sito "http://sub2.vostro-host.com/", questo link al file avrebbe dovuto rispettare la regola di essere comprensibile al software di raccolta statistiche.

Nel caso di nuovi link, tutto ciò diventa lavoro del redattore: è lui che deve fornire il link corretto per il download (copiandolo dalla vista di downalod del file, che ora monta rer.downloadurl)...

...ma ancora una volta: come sistemare il pregresso??

La soluzione è stata quella di scrivere un nuovo plugin che sfruttasse le caratteristiche di Plone scoperte per capire se i link, anche quando esterni, fossero link a file Plone.

Per fare questo occorre:

• cercare gli URL nel testo
• per ogni URL, tentare di scaricare lo stesso aggiungendovi in fondo "/at_download/file" (se ok: probabilmente è Plone!)
• se si ottiene una risposta con un header che identifica il nome reale del file, salvare questo nome
• generare l'URL aggiungendovi "/at_download/file" e il nome del file.

Il Cliente era interessato a sistemare solo i propri link interni (intesi come: link ad altri siti dell'organizzione) e quindi l'espressione regolare di ricerca è stata limitata agli URL contenenti il nome host corretto, anche perché aprire connessioni a URL esterni a un sito può (ulteriormente) rallentare la procedura.

Conclusione

La Storia ha avuto un lieto fine, anche grazie a una serie di prodotti con compiti ben separati.

Ma probabilmente varrebbe la pena sistemare tutto questo direttamente alla fonte: tra i tanti pregi di Plone c'è sempre stato quello di avere gli "URL parlanti", quindi credo valga la pena rendere gli URL ai file già leggibili dagli HTTP log.

Non ha senso (e confonde) avere più modi per accedere alla stessa informazioni in modi "simili".

Che ne dite?

L'immagine in testata è di mothemagicdragon.

Questa Storia parte da un Cliente non molto contento del modo in cui Plone gestisce i file.
Nel caso non lo sappiate, c'è una certa confusione a riguardo.

Se nel vostro sito Plone vi collegate all'indirizzo diretto a un file, nella forma...

http://vostro-host.com/percorso/al/file.pdf

...il file in questione viene "aperto direttamente": gli header inviati da Plone scatenano l'apertura del file "inline", quindi sfruttando eventuali plugin del browser, se presenti.
Questo tipo di comportamento ha problemi di usabilità: utenti che non capiscono di essere ancora "dentro al browser" potrebbero chiudere il browser pensando che si tratti di un programma esterno. Se l'utente poi vuole scaricare il file dal plugin, deve trovarne la funzione all'interno dello stesso.

Eppure se arrivate allo stesso file dall'interfaccia Plone (dal navigatore del sito, da una delle viste, ...) vi troverete a un URL diverso:

http://vostro-host.com/percorso/al/file.pdf/view

Questo è l'indirizzo della vista del contenuto file (file_view) da cui potete vedere alcune informazioni sul file e da dove viene mostrato il link per scaricarlo, che assume invece questa forma:

http://vostro-host.com/percorso/al/file.pdf/at_download/file

NB: per alcuni, passare prima dalla vista del contenuto file è solo una perdita di tempo... e un click inutile. Per altri, se il navigatore facesse scaricare direttamente il file (funzionalità semplice da ottenere con Plone), sarebbe inconcepibile: capirete quindi che non esiste una soluzione universale.

La Storia si complica

Il contenuto File in Plone è uno di quei pochi tipi dove il campo titolo non è obbligatorio.

Partendo da Plone 4 (con l'inclusione di plone.app.blob nel core Plone) è stata introdotta un'altra grossa differenza: prima di Plone 4, caricare un file con e senza titolo non aveva differenze sull'URL generato: l'id del file (che determinava anche l'URL) era sempre lo stesso: il nome del file caricato.
Con Plone 4 il campo titolo è rimasto opzionale ma, se venisse fornito, questo verrà utilizzato per generare l'id del contenuto (come per tutti gli altri tipo Plone).
Se dovessimo quindi caricare lo stesso "file.pdf" con il titolo "Il mio file PDF", otterremmo in realtà questo URL:

http://vostro-host.com/percorso/al/il-mio-file-pdf

TinyMCE (la Storia diventa un gran caos)

Avete mai fatto caso al modo in cui TinyMCE genera link ai file? Li tratta in modo diverso dagli altri contenuti?
No!

Usando il comodo plugin per i link interni, TinyMCE genera un semplice link diretto al file, che per quanto visto sopra è il link che determina l'apertura del file inline.

Vediamo di ricapitolare; la situazione è la seguente:

• dai navigatori Plone arrivo alla vista dei file ("/view")
• da questa vista ho disponibile il link per scaricare il file ("/at_download/file")
• usando link generati dall'editor ottengo l'apertura diretta del file inline.

...ed infine le statistiche

Il colpo di grazia ci viene dato dai sistemi di statistiche che analizzano i log. Esistono infatti software che, analizzando i log degli accessi HTTP, sono in grado di individuare se la risorsa scaricata è un file, e di quale tipo.

Il problema di questo approccio è che nel log HTTP non ci sono molte informazioni se non l'URL (questo è un limite universale dell'approccio... Plone e altri CMS non potrebbero fare nulla per evitarlo); per capire quindi se un dato URL si riferisce ad un file PDF, l'unico modo è sperare che l'URL stesso finisca con ".pdf". Nessun header può fare la differenza qui...

Se torniamo ai file di Plone, avrete notato come da quasi nessuno di questi si capisca che si sta per accedere ad un file PDF:

• http://vostro-host.com/percorso/al/il-mio-file-pdf
  non finisce con ".pdf"
• http://vostro-host.com/percorso/al/il-mio-file-pdf/view
  non finisce con ".pdf" ma almeno non mente! Non è un link al file, ma solo una vista
• http://vostro-host.com/percorso/al/il-mio-file-pdf/at_download/file
  non finisce con ".pdf"
• http://vostro-host.com/percorso/al/file.pdf
  questo andrebbe bene... peccato che l'unico caso in cui potremmo ottenere questo URL è non fornendo un titolo al file (potreste aggiungere il titolo dopo ma sarebbe troppo scomodo, e dovremmo essere certi che nessuno lo rinomini).

Tanto per essere chiari: il Cliente utilizza uno di questi sistemi di statistiche e si è trovato (giustamente) scontento della grande varietà di URL presenti.

Ci è quindi giusta questa richiesta:

• "niente attivazione di plugin, i file vanno scaricati"
• "voglio che gli URL dei file Plone indichino il formato del file".

Fase 1: fermare il problema

Analizzando la situazione, ci siamo resi conto che il comportamento corretto per scaricare file lo abbiamo solo tramite la chiamata a "/at_download/file", che però ha comunque dei problemi:

• non finisce col nome reale del file
• non è utilizzata da TinyMCE.

La fortuna ha voluto che il Cliente utilizzasse già da tempo (e con soddisfazione) una variante del plugin dei link a file in Plone: collective.tinymceplugins.advfilelinks.
Se fino ad allora questo plugin si era sempre limitato ad accorgimenti grafici atti ad aumentare l'usabilità dei link (in primis: fornire la dimensione del file che si sta per scaricare), ora poteva tornarci utile per sistemare una delle funzionalità che TinyMCE non offre: scegliere il tipo di link al file.

Abbiamo quindi rilasciato una nuova versione del prodotto che portasse una nuova funzionalità: poter scegliere se avere un link diretto al file (inline), un link alla vista (preview) del file o un link per scaricare il file - tramite un nuovo menù a tendina.

Per questioni di correttezza verso la comunità che già utilizza questo prodotto non sarebbe stato giusto scegliere un valore di default diverso da quello predefinito di TinyMCE, quindi è stato tenuto come valore predefinito il "link diretto al contenuto".
Ma non era nemmeno pensabile che gli utenti del Cliente cambiassero ogni volta quel menù a tendina... è stato quindi usato un prodotto aggiuntivo che "sistemasse" il valore predefinito (funzionalità nativa, prevista dalla nuova versione di collective.tinymceplugins.advfilelinks).

Bene! Ora i link ai file fatti tramite TinyMCE hanno iniziato ad essere link al download reale, tagliando fuori gli eventuali plugin.

at_download, Quel Permissivo

Ma rimane il problema cruciale delle statistiche.

Dopo aver eseguito qualche test ci siamo accorti che la chiamata a "at_download/file" può ricevere altri elementi di percorso senza inficiarne il comportamento.

La cosa forse è un po' strana, ma richiamando un URL Plone in questo modo...

http://vostro-host.com/percorso/al/il-mio-file-pdf/at_download/file/fasullo.doc

... non ottenete errori: L'URL scatena comunque il download del file (e negli header inviati c'è il vero nome "file.pdf"... non preoccupatevi).
Il sistema di statistiche però in questo caso avrebbe (erroneamente) capito che la risorsa scaricata era un file di Word (.doc).

Sfruttando questa "funzionalità" abbiamo reso collective.tinymceplugins.advfilelinks ancora più flessibile, rendendo possibile indicare, tramite un prodotto di terze parti, come generare gli URL nel caso di "URL alla preview" o "URL al download".
Nello stesso prodotto di cui sopra è stato quindi cambiato il valore per il download del file da "/at_download/file" a "/at_download/file/nome reale del file".

Infine, la cosa più semplice: cambiare la vista file_view perché mostrasse lo stesso URL di download modificato. Per fare questo è stato rilasciato un micro-pacchetto: rer.downloadurl.

Ok, missione compiuta: da ora in poi i link ai file saranno amichevoli con il software di statistiche!

... ma i vecchi link?!

Siete curiosi di sapere come finisce? Per ora ho già scritto troppo; per il resto della Storia ci rivediamo martedì prossimo!

Così l'evento è iniziato già la sera del 2, durante l'aperitivo dell'hotel.

In eventi come il Plog, la comunità Plone mostra le sue qualità migliori: giovialità e socievolezza.

Eventi come il Plog servono anche a stringere nuove amicizie, nuove collaborazioni o semplicemente ritrovare persone che vivono dalla parte opposta del globo e con cui magari si collabora giornalmente a rendere il nostro amato cms sempre più "cool".

Day 1... si aprano le danze!

Mercoledì 3, di buonora, sono iniziati i lavori dell'evento. Date le condizioni atmosferiche non ottime, tra i partecipanti si è subito diffusa la gag di rinominare l'evento in "Plone Open Hall" o "Plone Open Basement", per la location scelta per i talk.

Ad aprire le danze sono stati due famosi plonisti francesi, Thomas Desvain e Cédric Messiant. Thomas ha presentato una suite di prodotti molto interessanti per la delega di permessi agli utenti limitatamente ad un certo contesto di un sito Plone. Tra i prodotti presentati spiccano collective.local.adduser per delegare la creazione di utenti locali; collective.local.addgroup per la delega di creazione dei gruppi; infine collective.local.sendto per la delega di invio di email agli utenti. Tutti i prodotti di questa suite sono disponibili su github: https://github.com/tdesvenain.

Il collega Cédric ha presentato un'altra suite di prodotti per la gestione di una rete di contatti/esperti all'interno di un'azienda. La soluzione prevede di poter definire dei gruppi, dei ruoli nei gruppi e degli esperti per i ruoli. La metafora usata durante il talk rappresenta i gruppi con i raggruppamenti gerarchici di un esercito (armata, reggimento); i ruoli sono il corrispondente dei gradi dell'esercito (generale, comandante) e gli esperti sono i singoli soldati. La suite di prodotti è disponibile come al solito su github:

• https://github.com/collective/collective.contact.plonegroup
• https://github.com/vincentfretin/collective.contact.core
• https://github.com/vincentfretin/collective.contact.widget.

Dopo i colleghi francesi è stato il turno di quelli olandesi, con Guido Stevens che ha presentato la sua soluzione social per Plone, PloneSocial. La chiarezza della visione di cosa c'è nel futuro social di Plone ha lasciato molti piacevolmente impressionati. Il cuore del talk, più che l'insieme dei dettagli tecnici, è stata la presentazione di una roadmap per il completamento del social networking in Plone.

Studi di settore hanno dimostrato che le interazioni lavorative di tipo social all'interno di un'azienda aumentano la produttività dei dipendenti del 20-25%!

La suite di prodotti copre per ora le funzionalità di microblogging, activity stream, follow di utenti o di aree di contenuti e aree di team working. Più di un partecipante al talk era interessato a come avesse affrontato il problema delle performance e Guido ha dimostrato che, attraverso ingegnose soluzioni tecniche, è possibile assicurare la scalabilità sia in alto sia in basso del sistema.
Dopo una breve pausa, ha preso la parola il nostro Massimo per presentare l'esperienza di RedTurtle nel mondo del software agile, i problemi comuni e le soluzioni aziendali adottate, sia di tipo organizzativo interno sia come strumenti sviluppati, tra cui Penelope. Il nostro approccio e le nostre soluzioni hanno attirato l'interesse e le domande di molti colleghi Plonisti che si trovano ad affrontare tutti i giorni gli stessi problemi.

L'ultimo talk della mattinata è stato di Giorgio Borelli, collega plonista italiano, che ha raccontato l'ormai noto e apprezzato prodotto Plone per la geolocalizzazione, collective.geo e la sua roadmap per l'evento.

Nel pomeriggio i lavori sono ripresi con degli sprint su vari argomenti. Lo sprint in assoluto più partecipato è stato incentrato su una discussione sullo stato dell'universo dei prodotti Plone e su come migliorarne sempre più la qualità e la tracciabilità. Dalla discussione è nata l'idea di istituire un concorso annuale per i "migliori 50 prodotti di Plone", in modo da sfruttare questa piccola competizione per spingere la comunità a curare sempre più i propri prodotti.

Nel resto del pomeriggio ho partecipato al gruppo della documentazione, mentre Massimo a quello del Marketing. Nel nostro gruppo ci siamo occupati di trascrivere nero su bianco il processo di rilascio di una nuova release di Plone, le persone coinvolte e gli step da seguire. Abbiamo proseguito con la stesura della documentazione sul processo di installazione passo passo di Plone sui più diffusi sistemi operativi.

Day 2... the show must go on!

Il secondo giorno di conferenza si è aperto con un talk di Antonio De Marinis dell'Agenzia Europea per l'Ambiente (eea.europa.eu).

Lo scopo del talk è stato quello di presentare i lavori dell'Agenzia, fare una panoramica su cosa sia l'Open Data e presentare uno prodotti sviluppati, eea.daviz. Questo prodotto permette di visualizzare di dati provenienti dai dataset mondiali in forma di grafici.
A seguire ha preso la parola l'attuale presidente della Plone Foundation, Paul Roeland, che ha fatto un report sullo stato della fondazione, sui progetti aperti e sulle sovvenzioni per l'organizzazione di nuovi eventi.
Dopo una breve pausa ha preso la parola Érico Andrei di Simples Consultoria, l'azienda che quest'anno ha ricevuto l'incarico di organizzare l'annuale conferenza mondiale di Plone.

"...siamo qui per farvi vedere come spendiamo i soldi dell'Agenzia, che in fin dei conti, sono anche i vostri soldi!" (cit. A. De Marinis)

Come da previsioni, il talk è iniziato con un resoconto dello stato dei lavori dell'organizzazione dell'evento e delle location identificate. Dall'entusiasmo mostrato da Érico ci si aspetta che la Plone Conference 2013 sarà un evento da non perdere. Nella seconda parte del suo talk, Andrei è passato a presentare lo stato di avanzamento di un prodotto presentato in anteprima all'ultima PloneConf, collective.cover. Questo prodotto, molto interessante, ha lo scopo di fornire alle nostre redazioni uno strumento per la costruzione di homepage in maniera facile, veloce e estremamente flessibile. L'idea di base del prodotto non è nuova, esistevano già vari prodotti per questo scopo - come il più vecchio e famoso collective.portletpage -, ma collective.cover sembra un passo avanti per la flessibilità e per l'utilizzo di tecnologie all'avanguardia che entreranno in Plone nelle prossime release.

Nel pomeriggio, come il giorno precedente, sono ripresi gli sprint. Massimo ed io abbiamo continuato a partecipare ai gruppi del giorno precedente. I lavori della documentazione si sono concentrati sulla preparazione di uno script per l'installazione guidata di tutte le dipendenze di Plone. Lo script, grazie a una grafica minimale, guida l'utente nell'altrimenti delicato compito di preparare il sistema ad ospitare Plone. Il gruppo del Marketing si è concentrato invece sull'identificazione della lista di 50 prodotti "consigliati" di Plone.

Day 3... leaving Sorrento is never easy, I saw the light fading out!

Il dovere purtroppo non guarda in faccia nessuno. Il terzo giorno, infatti, la sveglia ci ha riportato alla realtà alle 5 am per prendere il treno che da Napoli ci avrebbe riportato a Ferrara. Dopo 7 ore di viaggio siamo tornati alla nostra città, con un carico di nuovi spunti di approfondimento su soluzioni e prodotti basati sul nostro amato cms Plone.

Quando sto per scrivere un nuovo post per il blog, il problema è sempre il solito: trovare un argomento interessante da proporre.

Sfortunatamente per voi, la risposta è sempre la stessa: migrazioni!

Come già detto in un precedente articolo, spesso le migrazioni sono anche il momento ideale in cui fare un'analisi del portale e individuare eventuali archetypes creati ad hoc che, col tempo, sono diventati inutili o addirittura da eliminare, perché mai utilizzati correttamente.

Se quei contenuti li vogliamo proprio eliminare, li cancelliamo direttamente dal portale e non ci si pensa più.
Discorso diverso, invece, se questi vanno mantenuti e magari "convertiti" in qualcosa di più standard, come ad esempio i contenuti base di Plone.

Ultimamente ho dovuto pensare proprio a come migrare 4-5 vecchi Archetypes ormai inutilizzati e farli diventare dei tipi base di Plone (Cartelle, Pagine ed Eventi).

La prima idea è stata quella di creare una serie di procedure come descritto nell'articolo di cui parlavo prima, ma poi mi sono chiesto se non esistesse un modo per rendere parametrizzabile questa operazione senza dover scrivere ogni volta 200 metodi uguali.

Visto che la migrazione che mi interessava era molto base e non avevo bisogno di eseguire nessuna operazione intermedia, ho deciso di creare un piccolo prodottino che mi aiutasse: rt.atmigrator.

Si tratta di un pacchetto che va inserito nel buildout e non ha bisogno di essere installato.

Fornisce una semplice vista (http://url-del-sito/@@migrate-types) che non fa altro che chiedere all'utente 2 cose:

• Il tipo di partenza (selezionabile tra i tipi aggiungibili nel portale)
• Il tipo di destinazione (selezionabile tra i tipi aggiungibili nel portale).

Una volta confermato, viene lanciato un metodo come quelli già descritti, che esegue la migrazione con Products.contentmigration utilizzando come parametri i 2 tipi impostati nel form.

Completata la migrazione, nel log c'è una descrizione completa delle operazioni svolte (ed eventualmente il traceback degli errori) e l'utente viene informato di quanti elementi sono stati aggiornati.

Il prodotto di per sé è molto semplice, dato che esegue una migrazione base da un tipo ad un altro.
Nulla vieta però di prevedere, in futuro, anche delle evoluzioni e supportare, ad esempio, una gestione di filtri per determinare i contenuti da migrare (oltre al solo tipo, magari anche un percorso o lo stato di pubblicazione), oppure delle operazioni pre e post migrazione per determinati tipi.

Il sorgente è disponibile su github, quindi si può consultare ed eventualmente modificare in un attimo.

L'API principale a cui si fa riferimento per aggiornare lo stato di un contenuto nel catalogo Plone è la chiamata a reindexObject:

>>> context.setTitle('Nuovo titolo')
>>> context.reindexObject()
>>> context.title()
'Nuovo titolo'

Fin qui, nulla di nuovo.

In alcuni casi è possibile limitare gli indici aggiornati a un sottoinsieme di quelli esistenti.

>>> context.setTitle('Nuovo titolo')
>>> context.reindexObject(idxs['Title', 'sortable_title', 'SearchableText'])
>>> context.title()
'Nuovo titolo'

In base all'attributo modificato, vale la pena aggiornare tutti gli indici che lo riguardano.

Quando la sicurezza incontra la ricerca

Un fatto meno noto: il catalogo di Plone è usato anche nella gestione della sicurezza.
In particolare esiste un indice dal nome allowedRolesAndUsers esplicitamente usato per una verifica di sicurezza: capire se un utente ha accesso a un contenuto (in pratica viene memorizzato nel catalogo se gli utenti hanno il permesso di "View" sul contenuto).

Perché tutto questo? L'alternativa sarebbe disastrosa in termini di prestazioni: caricare tutti i documenti risultanti dalla ricerca e verificare il controllo di sicurezza direttamente su questi.
Tale operazione può diventare molto lenta e dispendiosa, se pensiamo che una semplice ricerca testuale può portare a migliaia di risultati in un sito mediamente popolato.

E' quindi importante che questo indice sia sempre aggiornato. Per questo motivo, ogni volta che viene effettuata un'operazione che comporta un cambio di sicurezza di un contenuto (principalmente modifiche nella pagina di condivisione), l'indice viene aggiornato automaticamente.

Dato che una semplice chiamata al metodo reindexObject può essere relativamente dispendiosa (tenete sempre presente che Plone potrebbe indicizzare anche i file allegati e che l'operazione di re-indicizzazione di un file può essere piuttosto lenta), esiste un altro metodo che viene utilizzata al suo posto: reindexObjectSecurity.
Nel funzionamento base di Plone, questa chiamata si occupa di aggiornare solo l'indice allowedRolesAndUsers introdotto sopra.

Sicurezze alternative

Ma è vero che l'unico indice legato alla sicurezza sia allowedRolesAndUsers?
Nell'uso quotidiano di Plone sì, ma esistono alternative.

Vi porto due esempi.

collective.portlet.truereview

Sto parlando di un prodotto poco noto e di qualche anno fa: collective.portlet.truereview.

Questo prodotto applica lo stesso principio utilizzato col permesso "View" dall'indice allowedRolesAndUsers per un nuovo permesso legato all'attività di revisione dei contenuti: "Review portal content".
Per fare questo viene creato un nuovo indice: reviewerRolesAndUsers.

Lo scopo del prodotto è fornire una portlet di revisione alternativa per Plone che, a differenza di quella ufficiale, non richieda il caricamento del contenuto.
NB: il prodotto è fermo dal 2009, non sono certo che funzioni ancora ma lo trovo piuttosto didattico.

collective.localrolesdatatables

Il secondo esempio è legato al più recente collective.localrolesdatatables.

Questo prodotto vuole fornire una vista che permetta di ispezionare lo stato della sicurezza e delle condivisioni in un sito Plone.
Per fare questo è necessario capire su quali contenuti ci siano effettivamente delle personalizzazioni locali della sicurezza, ovviamente senza caricare i contenuti per non ricadere nel solito problema di prestazioni (ormai ci siamo capiti, vero?!).
L'approccio usato è quello di creare un nuovo indice "hasLocalRoles", un valore booleano che indica se un contenuto ha ruoli locali impostati o meno.

Espandere il funzionamento di reindexObjectSecurity

E' stato proprio utilizzando di recente collective.localrolesdatatables che mi sono imbattuto in un bug (di cui sono certo soffra anche collective.portlet.truereview):
il prodotto funziona a dovere, ma se la sicurezza di un contenuto viene aggiornata, l'indice "hasLocalRoles" non viene modificato a sua volta, almeno non fin quando l'intero documento verrà modificato (e quindi completamente reindicizzato).

Qual è il problema? Il metodo reindexObjectSecurity "non sa" che anche questo indice fa parte della sicurezza del sito.

Come risolvere?

Se andiamo ad analizzare l'implementazione di reindexObjectSecurity, troviamo questa riga di codice:

catalog.reindexObject(ob, idxs=self._cmf_security_indexes,
                      update_metadata=0, uid=brain_path)

Viene quindi chiesto di reindicizzare nel catalogo il documento (ob) e di limitarsi agli indici definiti nella tupla self._cmf_security_indexes (quindi non tutti gli indici).

_cmf_security_indexes è un attributo di classe definito per CatalogAware, nel pacchetto Products.CMFCore. La sua definizione è la seguente:

_cmf_security_indexes = ('allowedRolesAndUsers',)

La soluzione è molto semplice: estendere la lista di indici registrati in questo attributo (qui come ho modificato collective.localrolesdatatables):

from Products.CMFCore.CMFCatalogAware import CatalogAware

CatalogAware._cmf_security_indexes += ('mioNuovoSecurityIndex',)

Problemi?

Questo tipo di intervento ha un effetto collaterale: modifica l'attributo a livello di classe e si rispecchia quindi su tutti i siti Plone presenti nell'installazione. Potreste anche trovarvi nella situazione in cui il prodotto che necessita di questa modifica sia installato su un solo sito Plone, quindi il nuovo indice non sia presente in altri, eppure la modifica sia comunque applicata.

E' un problema? Per fortuna no!
Il catalogo Plone è molto tollerante: se viene chiesta la reindicizzazione di un indice non esistente, questo fallisce l'operazione senza sollevare eccezioni.

L'immagine di testata è di Alexandre Dulaunoy.

I campi del contenuto generato saranno esattamente i campi del modulo che hai configurato!

Inoltre, una volta generato il contenuto a seguito della sottomissione del form, potrai controllare la sua visibilità e il suo accesso applicando su di esso un specifico workflow come per un normale tipo di contenuto.

I campi del modulo diventeranno i campi dell'oggetto creato: potrai quindi modificare il loro valore. Questa funzionalità è realizzata mediante schemaextender, che è stato usato nel prodotto uwosh.pfg.d2c per aggiungere i campi extra del modulo al tipo di contenuto.

Ora vediamo come applicare l'adattatore ai form in tre mosse e come configurare i campi principali che lo caratterizzano.

Il prodotto uwosh.pfg.d2c aggiunge un elemento "Save Data to Content Adapter" al menù a discesa "Aggiungi nuovo..." per un form di PloneFormGen.

Una volta abilitato l'adattatore, quando un utente invia un modulo verrà creato un nuovo contenuto con i dati inseriti nel form.

Vediamo in dettaglio come applicare l'adattatore:

1. aggiungi il form, e con "QuickEdit" inserisci tutti i campi di interesse
2. aggiungi l'adattatore al form
3. attiva l'adattatore: scegli "QuickEdit" sul form e, nella lista delle azioni, seleziona l'adattatore appena aggiunto.

Troverai i contenuti generati dopo la compilazione del form nella cartella dell'adattatore.

Campi di configurazione dell'adattatore

Il tipo di contenuto dell'oggetto generato

Il campo "Saved entry content type" si riferisce al portal type dell'oggetto usato per il salvataggio dei dati all'invio dei moduli.

A questo scopo il prodotto fornisce un nuovo tipo di contenuto "FormSaveData2ContentEntry", ma è possibile clonare "FormSaveData2ContentEntry", per usare un proprio tipo personalizzato, in tre modi:

• tramite l'interfaccia fornita dal prodotto, alla creazione/modifica dell'adattatore, facendo click sul bottone "Add new type"
• copiando manualmente il tipo "FormSaveData2ContentEntry" nel portal_types tool (via ZMI) e poi rinominarlo in modo appropriato
• aggiungendo il clone del tipo "FormSaveData2ContentEntry" al types tool via codice genericsetup profile.

Una volta creato, il nostro nuovo tipo di contenuto sarà presente tra le opzioni del save data adapter; è necessario selezionarlo esplicitamente e quindi tornare in modifica dell'adattatore se lo abbiamo creato con gli utimi due metodi; altrimenti verrà applicato il valore di default FormSaveData2ContentEntry.

I campi relativi al titolo

Il campo "Title Field" ti permette di scegliere tra i vari campi del form quale sarà il campo da cui verrà preso il titolo dell'oggetto generato.

Se per il titolo del futuro oggetto non vuoi usare nessuno dei campi del form, puoi utilizzare un'altra funzionalità dell'adattatore: "Dynamic title override", che ti permette di inserire un'espressione TALES valutata al momento della generazione dell'oggetto per determinare dinamicamente il titolo. In questo modo puoi attribuire al contenuto titoli più complessi, come ad esempio il nome del form (risalendo all'oggetto padre) seguito dalla data di creazione.

python:'%s %s' % (here.aq_inner.aq_parent.aq_parent.Title(),here.created().strftime('%d/%m/%Y'))

Come ultimo, il campo dell'adattatore "Nice Ids" ti consente di generare per l'oggetto un nome breve partendo dal titolo del form.

Permessi e sicurezza

La compilazione di un form può essere effettuata anche da un utente anonimo, se tale modulo è pubblico.

Tuttavia, se l'invio del form è seguito dalla creazione dell'oggetto corrispondente, come nel nostro caso, l'anonimo non ha i permessi sufficienti per creare un oggetto e di conseguenza per compilare il form.

Perciò l'adattatore prevede un campo "Avoid Security Checks" per evitare i controlli di sicurezza nella creazione di un oggetto, consentendo quindi anche agli utenti anonimi di completare il form.

Un altro modo per fornire questa possibilità senza evitare i controlli di sicurezza, è modificare il workflow e i permessi del tipo di contenuto generato a favore dell'utente anonimo.

In conclusione

Il prodotto ti fornisce un adattatore per PloneFormGen e un nuovo tipo di contenuto che sarà quello generato una volta sottomesso il form su cui hai applicato l'adattotore. Puoi decidere di utilizzare quel tipo oppure puoi personalizzarlo clonandolo.

Puoi inoltre configurare il punto da cui verrà preso il titolo e permettere anche agli utenti anonimi di usare il tuo form, senza che la creazione del contenuto fallisca per permessi insufficienti.

Personalmente ho trovato molto utile uwosh.pfg.d2c e ringrazio l'autore del prodotto Nathan Van Gheem e i contributori Author T. Kim Nguyen, Lurker Petri Savolainen, che mi hanno fornito molte delle funzionalità di cui avevo bisogno. Se vi sembra che faccia anche al caso vostro, potete appronfondire con altra documentazione.

Anche se il prodotto è legato ad Archetypes, il framework che Plone sta lentamente sostituendo con Dexterity e in futuro è possibile che prodotti come questo non servano più, al momento è ancora un'ottima risorsa!


La foto in testata è di Images_of_Money

Il perché è ovvio: ogni persona ha come minimo 50 registrazioni a siti vari e, soprattutto, ogni internauta di oggi ha un profilo su più social network.
Da qui la brillante idea di permettere di accedere ai siti direttamente con un altro account che fornisca l'identità.

Plone non poteva certo rimanere indietro su questo fronte e quindi ecco plonesocial.auth.rpx: un pacchetto che utilizza i servizi di autenticazione RPX offerti Janrain.

Una nostra personalizzazione

Il plugin di COM.lounge non rispondeva però appieno alle necessità di un nostro cliente, il quale non voleva l'autenticazione automatica indiscriminata da parte di tutti ma un secondo step di registrazione in cui richiedere alcuni dati aggiuntivi.
Abbiamo quindi deciso di estendere il prodotto originale sviluppandone una nostra versione in cui:

• abbiamo aggiunto un campo "telefono" al profilo utente
• abbiamo aggiunto un form obbligatorio per effettuare la registrazione al portale
• abbiamo modificato il plugin di autenticazione in modo da lasciare anonimi tutti gli utenti che non hanno completato il form.

Configuriamo il sistema

La prima cosa da configurare è Janrain stesso che, in linea con la politica di questo sistema, non fornisce la possibilità di una registrazione diretta al sistema ma solo tramite un account preesistente.

 

 

 

 

 

 

Dopo aver confermato le informazioni del proprio account, bisogna scegliere un nome per la propria applicazione.

 

 

 

 

 

 

 

 

Il dominio RPX, basato sul nome che avete scelto per la vostra applicazione, insieme ad alcune altre chiavi vanno a comporre le informazioni di configurazione. Queste sono necessarie a configurare il nostro pacchetto Plone.

 

 

 

 

 

 

A questo punto la configurazione “Plone to RPX” è completa, ma ora bisogna configurare RPX perché si colleghi ai vari provider di Online ID per i quali si vuole garantire l’accesso sul nostro portale Plone.

La home dell’applicazione presenta alcune informazioni sugli accessi, limitate se si sta utilizzando la versione gratuita, molto più complete se avete acquistato una versione plus, pro o enterprise.
Dei vari menù e quick links disponibili quello che ci interessa è il menu “Development -> Provider Configuration”.

Nell’immagine qui sopra si può vedere che, al momento, la mia applicazione è configurata per gestire l’accesso tramite Facebook e Google; l’altro dettaglio visibile è che molte delle opzioni sono disponibili solo per le versioni a pagamento.

 

Ora vediamo come configurare RPX per connettersi ad uno degli Online ID disponibili e prendiamo come esempio la configurazione per Twitter.

Cliccando sul pulsante “Configure” parte un wizard che fa compiere tutti i passi necessari.

Per collegare Twitter, ma anche Facebook tra quelli che ho avuto modo di provare, occorre attivare il proprio account come “Developers”. Nulla di particolarmente difficile, sul web si trovano tutte le informazioni necessarie, ma è un’ulteriore passaggio da fare.

Una volta effettuato l’accesso, bisogna creare la propria applicazione tramite la compilazione di un semplice form dove è necessario inserire i parametri indicati nella seconda schermata del wizard.

La terza schermata dice di impostare il permesso di “lettura e scrittura” da parte della vostra applicazione su Twitter, mentre l’ultimo passaggio da fare è impostare in RPX i parametri di “customer Key” e “Customer Secret” per effettuare il collegamento tra i due sistemi.

I wizard di configurazione non sono tutti uguali, perché ogni provider necessita di configurazioni particolari, ma si concludono tutti con la richiesta dei parametri per il collegamento tra i sistemi.

Per concludere la configurazione di RPX, bisogna andare a impostare il widget di Sign-in che verrà mostrato nel proprio sito scegliendo i tipi di account che sono stati precedentemente configurati.

 

A questo punto tutto è pronto per effettuare l’accesso con Online ID in Plone; buon login!

L'effetto è spiacevole, perché parte dei campi di input invadono i riquadri della colonna destra.

Dopo varie ricerche ho trovato il bug ufficiale: "Sunburst Theme: Expanding textarea's right portlets bleed through".

Una soluzione

span.ploneSkin table.mceToolbar {
     float: none;
}

La mia soluzione

function myCustomInitInstance(inst) {
    
    // tabella contenitore che possiede le dimesioni
    var tinytable = $("table.mceLayout");

    // elemento td che contiene le toolbar
    var tinytoolbar = tinytable.find("tr.mceFirst td.mceToolbar");

    // fissiamo le dimensioni sul contenitore delle toolbar
    $(tinytoolbar).css("width",$(tinytable).css("width"));
}

tinyMCE.init({
    ...
    init_instance_callback : "myCustomInitInstance"
});

function myCustomInitInstance(inst) {
    alert("Editor: " + inst.editorId + " is now initialized.");
}

Il formato della funzione è: InitInstance (inst), dove inst è l'istanza dell'oggetto editor.

...
var init_dict = {
    ...
    init_instance_callback : "myCustomInitInstance"
}
...

td.mceToolbar {
     display:block;
}

Con queste brevi linee di codice possiamo evitare che l'editor invada la colonna laterale destra. Il passo successivo sarà quello di investigare su come questa soluzione diventi definitiva per il bug. Altri suggerimenti per risolvere il problema sono ben accetti!

La foto in testata è di bowenmurphy.

Cercando sul web, vi renderete conto che i plugin Javascript disponibili sono molti, ma uno mi ha colpito in particolare: jQuery.DataTables.js. Semplice da usare, funzionalità di base estese, molti plugin aggiuntivi e, non da ultimo per un plonista, esiste una versione già "pacchettizzata" per Plone su pypi.

Introduzione del plugin nelle pagine HTML

Per utilizzare questo plugin, tutto quello che bisogna fare è inserire nella pagina jquery.dataTables.css e jquery.dataTables.js.

Come detto esiste anche la versione pacchettizzata di questa libreria: è un porting realizzato registrando le risorse javascript e css per poterle inserire nel portal_javascript e nel portal_css e utilizzarle all'interno di Plone; chi volesse più informazioni le può cercare su pypi: collective.js.datatables.

Utilizzo base del plugin

Una volta introdotte le risorse Javascript e css nella pagina, per cominciare a utilizzare DataTables è sufficiente avere una tabella e inizializzarla tramite il costruttore del plugin:

  jq('#table_id').dataTable()
 

Facendo questo, si passa da una tabella come questa:

a una tabella come questa:

Come si può vedere, con una riga di Javascript nella tabella abbiamo già aggiunto:

• batching e navigazione delle pagine della tabella;
• ordinamento delle colonne;
• filtro sul testo della tabella.

Altre funzionalità

Questo plugin, come si può vedere dalla documentazione sul sito, presenta molte altre funzionalità; ma ce ne sono alcune molto utili su cui spenderò qualche parola.

Traduzioni

Il plugin è traducibile in ogni sua label. Per farlo, si può procedere tramite un vocabolario di traduzioni durante l'inizializzazione del plugin in questo modo:

 jq(document).ready(function(){
   jq('#table_id').dataTable({
     "oLanguage":{
         "sLengthMenu": "Visualizza _MENU_ elementi per pagina",
         "sZeroRecords": "Nessun elemento trovato",
         "sInfo": "Visualizzati da _START_ a _END_ di _TOTAL_ elementi",
         "sInfoEmpty": "Visualizzati da 0 a 0 di 0 elementi", 
         ....
         }
      });
    });
 

Un approccio alternativo può essere quello di usare l'attributo oLanguage passando il path di un oggetto "callable" del server che ritorni le informazioni relative alle traduzioni. Questo è molto comodo quando si lavora con il pacchetto per Plone, perché nelle ultime versioni è stata introdotta una vista che, una volta chiamata dal plugin, tornerà il vocabolario con le traduzioni:

  
  jq(document).ready(function(){
     jq('#table_id').dataTable({
        "oLanguage":{
           "sUrl": "@@collective.js.datatables.translation",
         }
      });
   });
 

In questo modo il plugin verrà visualizzato nella stessa lingua del browser, se la traduzione lato Plone esiste.

Ordinamento: quando l'alfabeto non basta!

L'ordinamento di base di DataTables è quello alfabetico e tiene in considerazione caratteri e numeri, ma non è inusuale che venga chiesto di ordinare le colonne della tabella anche in base ad altri criteri. Vediamo cosa si può fare, ad esempio, se viene chiesto di ordinare una colonna in base alla stringa scritta al suo interno, sapendo che quella stringa è una data nel formato gg/mm/aaaa.

Il plugin è scritto in jQuery, per cui sfruttiamo lo stile usato da jQuery per estendere i plugin. Guardando codice ed esempi, si può vedere che DataTables usa 3 funzioni per fare l'ordinamento di una colonna: una funzione prepara i dati per il confronto fra loro e le altre due fanno i confronti per l'ordinamento crescente e decrescente.

Potremo quindi scrivere codice come questo:

  
  jq(document).ready(function(){
     jq.extend(jq.fn.dataTableExt.oSort,
           {
           "date-ita-pre": function(a){
               // ci aspettiamo date nel formato DD/MM/YYYY
               // se le trasformiamo nel formato inglese sono ordinabili
               var itaDate = a.split('/');
               if (itaDate == "")
                   return 0;
               return (itaDate[2] + itaDate[1] + itaDate[0]) * 1;
               },
           "date-ita-asc": function(a,b){
               return ((a<b)? -1 : ((a>b) ? 1: 0));
               },
           "date-ita-desc": function(a,b){
               return ((a<b)? -1 : ((a>b) ? 1: 0));
               }
...
 });

 jq('#table_id').dataTable({
 "aoColumn": [null, ... , ..., {"sType": "date-ita"}]
 });
 });

Analizziamo il codice qui sopra partendo... dalla fine! Nelle ultime righe, inizializziamo il plugin impostando l'ordinamento delle colonne tramite una lista: ogni elemento della lista corrisponde a una colonna. Se si usa null, si utilizza l'ordinamento standard. Per l'ultima colonna della tabella, stiamo dicendo di utilizzare l'ordinamento "date-ita". Tramite questa stringa, il plugin sa che esistono 3 funzioni Javascript, precedentemente dichiarate, che permetteranno di preparare il dato e confrontarlo per ordinarlo rispetto agli altri dati.

Subito sopra, infatti, possiamo vedere che, mentre le ultime due funzioni si occupano di fare il confronto fra due valori per ordinarli fra loro, la prima prende in ingresso una stringa, la spezza in corrispondenza della '/' e la ricompone secondo l'ordine inglese (anno, mese, giorno), che è l'ideale per ordinare una data. La moltiplicazione per 1 viene fatta per fare casting della stringa a intero e poter fare così dei confronti fra interi. Allora sarà facile per le altre funzioni decidere se 20130102 è maggiore o minore di 20130103 e così via.

Navigazione alternativa nella paginazione

Questa in realtà è una finezza ma, personalmente, più che una navigazione che permette di muoversi solo tra le pagine "precedente" e "successiva", preferisco una paginazione più completa che mi permetta di saltare anche alcune pagine.

  
  jq(document).ready(function(){
     jq('#table_id').dataTable({
           "sPaginationType": "full_numbers",
           ...
      });
   });
 

Questo ci permette di avere una navigazione come quella mostrata nella figura che segue:

Conclusioni

La lunghezza del post non rende onore alla semplicità d'uso del plugin: una volta aggiunto a una pagina, bastano 5 minuti di orologio per poter avere tabelle con tutte le funzionalità necessarie a mostrare e elaborare grosse moli di dati. Ho provato il plugin anche utilizzando tabelle con circa un migliaio di elementi, e i tempi di risposta sono rapidissimi.

Inoltre, guardando la documentazione, ci si può rendere conto che ci sono ancora molte funzionalità da poter sfruttare. Per me, ad oggi, è sicuramente il primo plugin da tenere in considerazione quando si devono mostrare dati tabellari.

Con questa vista si possono anche fare alcune operazioni come il copia/incolla di contenuti, il riordino di elementi trascinandoli e cambiare il criterio di ordinamento dei contenuti visualizzati a seconda di alcuni indici come il titolo o la data di modifica.

E se noi volessimo uno strumento più completo, e fare operazioni più complesse?

Per risolvere queste "mancanze", esiste un prodotto che ci può aiutare: wildcard.foldercontents.
E' un plugin per Plone sviluppato da Nathan Van Gheem che riprende il lavoro iniziato dal nostro Luca Fabbri con collective.sortmyfolder e aggiunge altre interessanti funzionalità.

In sostanza sostituisce la vecchia vista contenuti con un nuovo template. Come si può notare (a parte la grafica leggermente modificata) le funzionalità di base sono rimaste tutte, con in più alcune aggiunte:

1. Possibilità di modificare il criterio di ordinamento degli elementi in base a diversi indici (ordine cartella, titolo, data di modifica, data di creazione), sia in ordine crescente che decrescente
2. Supporto alla selezione multipla con shift+click
3. Possibilità di spostare un elemento singolo in cima o in fondo
4. Possibilità di effettuare un upload di file multiplo
5. Possibilità di riordinare gli elementi della cartella in base a un determinato indice.

Il prodotto funziona decisamente bene e soprattutto è un ottimo strumento a disposizione dei gestori del sito che, in questo modo, possono avere un controllo più completo dei contenuti delle cartelle.

E poi è completamente tradotto in italiano!, dunque perché non provarlo?

 // Tramite jQuery si prende la lingua corrente dall'attributo del tag html 
 var lang = jq('html').attr('lang');

 // si dichiara il vocabolario con le traduzioni nelle varie lingue
 var messages = {'it': 'Benvenuti',
                 'en': 'Wellcome',
                 'es': 'Bienvenido',
                 'fr': 'Bienvenue'};

 // apriamo l'alert scegliendo la traduzione opportuna.
 alert(messages[lang]);

Se la pagina web che stiamo creando ha molte parti caricate via javascript, e quindi molti testi e parole da presentare tradotte, questo approccio è scomodo; innanzitutto perché si rischia di dover mantere molto codice solo per le traduzioni.
Se siamo in un caso come questo, il sito sviluppato probabilmente è già multilingua e i dati verranno presentati correttamente. Per quanto riguarda i testi da mostrare in javascript, è meglio sfruttare un motore di traduzioni, e in Plone, grazie alla community, un'utility di questo tipo esiste già: jarn.jsi18n. Grazie a questo prodotto, infatti, è possibile sfruttare appieno il message factory di plone e tutti i suoi file di traduzioni.

Come usarlo

Il funzionamento è semplice. Una volta installato il prodotto nel sito, tutto quello che dobbiamo fare è caricare un catalogo e creare un message factory nel javascript che scriviamo:

 // Tramite jQuery si ottiene la lingua corrente dall'attributo del tag html
 var lang = jq('html').attr('lang');
  
 // Dato un dominio di traduzioni e una lingua si ottiene un catalogo dal server;
 // questo restituirà al browser un vocabolario tipo
 // {..."from_date": "Dal", "to_date": "Al", ...}
 jarn.i18n.loadCatalog('fta.at', lang);
 
 // Creiamo un message factory javascript che sfrutta il catalogo restituito dal server
 mf = jarn.i18n.MessageFactory('fta.at');
 

Da qui in poi si potrà procedere utilizzando il message factory in modo molto 'plonish':

 // Si può iniziare a tradurre stringhe
 > mf('How to get here'):
 "Come arrivare"

E se abbiamo dei testi da costruire dinamicamente: 

 
 // Si possono tradurre anche stringhe in modo più dinamico, esattamente come in plone.
 > mf('other_results');
 "... e altre ${results} voci"

 > mf('other_results', {'results': 10});
 "... e altre 10 voci"

Under the hood

Come funziona tutto questo? Guardando il codice, ci si può rendere conto di come cose utili e funzionali possano essere create in modo semplice. Il pacchetto si compone di una vista e di un javascript. La vista è una classica BrowserView Plone che restituirà una stringa json con i dati richiesti:

 
 def __call__(self, domain, language):
     ...

     # Si ottiene l'utility plone per le traduzioni
     td = queryUtility(ITranslationDomain, domain)
     if td is None or language not in td._catalogs:
         return

     # Si ottiene il catalogo per il dominio nella lingua richiesta
     mo_path = td._catalogs[language][0]
     catalog = td._data[mo_path]._catalog
     if catalog is None:
         td._data[mo_path].reload()
         catalog = td._data[mo_path]._catalog
     ...

     # si restituisce il catalogo in formato json. 
     # Qualcosa del tipo: '{..."from_date": "Dal", "to_date": "Al", ...}'
     response.setBody(json.dumps(catalog))
     return response

Il javascript si occupa della chiamata al server per ottenere il catalogo che verrà gestito interamente lato client: una cosa molto interessante in questa gestione è, nei browser che lo consentono, l'uso dello storage del browser, tramite cui si riesce a fare caching di questo catalogo e non ricaricarlo ogni volta che si chiama una pagina:

 
 // si salva il catalog nello storage con una chiave associata
 var key = domain + '-' + language;

 // se abbiamo già quella chiave nello storage verificheremo se il catalogo è ancora valido.
 if (key in localstorage) {
     if ((Date.now() - parseInt(localstorage.getItem(key + '-updated'), 10)) < ttl) {
         var catalog = JSON.parse(localstorage.getItem(key));
         jarn.i18n._setCatalog(domain, language, catalog);
         return;
         }
     }

Come sempre, conoscere bene l'architettura e i componenti di Plone permette di svolgere lavori più o meno complicati in modo semplice, ma soprattutto pulito.

Recentemente, grazie alla mia doppia partecipazione nei team Lotus ® Notes / Plone, mi è stato proposto di fare alcuni test su Plomino.

Installazione

L'installazione è piuttosto semplice, se si ha dimestichezza con i buildout; è già tutto pronto, bastano pochi comandi:
(potete trovare i sorgenti qui)

io@dev:~$ git clone https://github.com/plomino/Plomino my_app
io@dev:~$ cd my_app
io@dev:~$ virtualenv .
io@dev:~$ . bin/activate
io@dev:~$ ./bin/python bootstrap.py
io@dev:~$ ./bin/buildout
io@dev:~$ ./bin/instance fg 

Fatto!

Come dice Eric Bréhault (project owner), Plomino si propone come “web application builder”, e nella semplicità ha il suo punto di forza.
Non a caso, in alcune slide proposte da Eric, viene fatto riferimento alla lenta curva di apprendimento di Plone e quindi alle difficoltà incontrate dai programmatori meno esperti, per mettere in risalto le doti di Plomino.

A questo scopo il team di sviluppo si è concentrato nel fornire semplici funzioni per la creazione di applicazioni web direttamente da interfaccia grafica, realizzate partendo da concetti facili presi in prestito dal noto e glorioso Lotus Notes ®, rendendo Plomino un prodotto che offre l'opportunità di cimentarsi nella creazione di applicazioni relativamente complesse anche ai meno esperti.

Ricca la "dotazione di serie", Plomino di base implementa:

• Form di inserimento direttamente realizzabili in WYSIWYG, comportamenti hide-when, subform, validazione campi personalizzabile
  (In Plone potrebbe essere paragonato a un content-type dinamico)
• Tool di generazione chart e mappe
• Viste indicizzate e categorizzate
  (Le viste Lotus corrispondo alle collezioni in Plone, sono praticamente query su database in base al tipo di documento. Una particolarità delle viste Lotus consiste nella possibiltà di raggruppare i risultati per categorie visualizzabili in una vista in sezioni espandibili)
• ACL/ruoli
• Azioni.
  (Sono molto simili alle action in Plone quindi associabili a pulsanti o link)
• Form di ricerca
  (Ricerca personalizzabile)
• Replica server-to server
  (Permette di trasferire contenuti e quindi replicare i dati da server a server su database differenti)
• Agenti schedulati
  (Programmi che posso essere lanciati a comando o programmati per essere eseguiti in stile cron)
• Tool di migrazione automatica da Lotus Domino (plomino.dominoimport).
  
  

"Solid as Zope, clean as Plone, easier than Django. Plomino"

Un'applicazione "tipo" realizzabile in Plomino corrisponde a grandi linee a un'applicazione Lotus ® Notes client side stile 6.5 (quindi prima dell'introduzione delle Xpages), composta da alcuni form di inserimento e varie viste per raggruppamento e/o filtro dei documenti. Il vantaggio offerto è dato dalla semplicità di realizzazione, interamente da web e con pochi click.

Approfondendo alcuni aspetti tecnici, posso dire che ho trovato molto semplice lavorare con le formulas, perché i metodi messi a disposizione nelle classi rispecchiano molto i metodi noti nell'ambiente di casa IBM, come per esempio:

• createDocument(self)
  Returns a new empty document
• deleteDocuments(self, ids=None, massive=True)
  Batch delete documents from database. If massive is True, the onDelete formula and index updating are not performed
• getAllDocuments(self)
  Returns catalog brains for all the PlominoDocument objects stored in the database
• getCurrentUserRights(self)
  Returns the current user’s access rights
• getDocument(self, docid)
  Returns the PlominoDocument object corresponding to the identifier, or none
• getForm(self, formname)
  Returns the PlominoForm object corresponding to the identifier
• getUserRoles(self)
  Returns all the roles declared in the database
• getViews(self)
  Returns all the PlominoView objects stored in the database
• isCurrentUserAuthor(self, doc)
  Returns True if the current user is author of the given document or has the PlominoAuthor right
• refreshDB(self)
  ...

L'unico linguaggio per interagire con il database in Plomino è Python, diversamente da Lotus che invece ha a sua disposizione LotusScript, Javascript, Java e Formulas, ma onestamente a mio avviso quest'ultimo approccio tende a confondere più che facilitare (+1 per Plomino).

Comoda la possibilità di importare ed esportare le applicazione via XML; gli esempi pubblicati sul sito sono installabili direttamente da interfaccia web.
Non mi piace, invece, l'implementazione del comportamento hide-when, troppo articolata; risulta più pratica nel client di sviluppo Lotus ® Notes.

Una cosa che mi ha fatto sorridere è la possibilità di fare quello che tecnicamente corrisponde a una @dblookup in Lotus (in pratica una query su database), anche nelle colonne di visualizzazione all'interno di una vista, ahimè uno dei limiti di Lotus mai superato in 20 anni...

Per iniziare, consiglio la visione di questo semplice tutorial online:

Conlusioni

In conclusione il mio giudizio è positivo; in genere non amo l'approccio WYSIWYG, però le circostanze assumono un ruolo importante: molto dipende, infatti, dal tipo di applicazione che si vuole sviluppare.
Forse Plomino è più adatto a chi non ha modo di approfondire Plone o per chi è, semplicemente, alle prime armi.

Si comincia

Il nostro Ente fittizio ha una regola: ogni nuovo dipendente, se necessita di una connessione Internet dal proprio computer, deve richiedere l'attivazione della stessa tramite un modulo (ah... la cara vecchia burocrazia).

Il form di generazione di questo documento si trova in un'area della nostra intranet, una sezione dell'ufficio IT pubblica ed accessibile a tutti.
Il form è stato generato dall'ufficio IT stesso chiedendo i pochi dati necessari.

Questo PloneFormGen usa il nostro adattatore, configurato per salvare i dati in una cartella della sezione ("Archivio richieste") e per "leggere" l'e-mail del responsabile dell'utente che fa la richiesta dal campo "Indirizzo e-mail del mio responsabile".

Sì, avete capito bene!
L'integrazione di Plone con un organigramma aziendale è fattibile in vari modi ma la soluzione più semplice (che ha suggerito il cliente stesso) è che sia l'utente richiedente a indicare il proprio responsabile.
Questa è ovviamente una delle prima cose che potrebbe non piacervi del prodotto e che qualcuno potrebbe voler personalizzare; che possiamo dire… siete i benvenuti!
Ma lasciatemi dire che finora questo approccio ha funzionato molto bene (ora vedremo perché).

Questo stesso prodotto può essere usato (con form completamente diversi) per altre attività: richiesta delle ferie, prenotazione risorse, ...

Workflow e sicurezza

Cosa succede dopo?

Al salvataggio del form viene generato un nuovo tipo di contenuto di tipo "Modulistica Online", che non è altro che una copia della pagina Plone.
Da qui nasce il motivo per cui è lasciata libertà di selezionare che cosa generare: l'unico limite imposto è che il tipo di destinazione sia una qualche forma di documento (tecnicamente parlando: abbia il campo di testo "text").

L'utente che compila il form deve poi avere i diritti per generare quel contenuto all'interno della cartella di destinazione (nella quotidianità di Plone: deve essere "Contributore" nella cartella).

I dati inseriti nel form vengono quindi raccolti e riversati nel nuovo documento.
Il documento rispetta un workfklow specifico del prodotto ed è in uno stato privato, visibile solo all'autore della richiesta, e attende di essere inviato per l'approvazione (l'utente ha la libertà di modificare la richiesta, accedendo al campo di testo).

Il nostro adattatore ha però intrapreso un'ultima azione prima di abbandonare definitivamente il campo: cercare l'utente con l'e-mail segnalata nel campo del proprio responsabile.
Se lo trova: assegna a quell'utente il ruolo di "Editor" nello specifico contesto del contenuto generato. Se non lo trova: riporta un errore e non permette di salvare il modulo.

Il responsabile riceve un'email (il cui testo è personalizzabile dalla configurazione dell'adattatore) che lo informa della presenza di un documento che attende la sua approvazione e il link per raggiungerlo in un click.

Il responsabile può modificare il contenuto, poi può approvare o rifiutare. Nel primo caso la palla passa all'evasore finale, nel secondo caso l'utente viene avvertito del rifiuto.

Chi è l'evasore finale?
E' la persona incaricata della chiusura della richiesta, in questo esempio è il membro dell'IT che si occupa di abilitare l'utente; anche lui può rifiutare o approvare la richiesta (con mail di notifica).
Come viene identificato?
L'evasore finale non è (obbligatoriamente) una singola persona ma spesso è un gruppo, e non è responsabile solo della richiesta specifica ma di tutte le richieste di attivazione Internet.
Per questo motivo usiamo semplicemente i ruoli locali di Plone, assegnando il ruolo di "Revisore" al gruppo interessato sulla cartella archivio.

La sicurezza del sistema è data dall'evasore finale. Se un utente tentasse di "fare il furbo" e auto-referenziarsi come responsabile di se stesso avrebbe due problemi:

• il tutto viene tracciato dal sistema di wokflow di Plone (e questo spesso basta da sé)
• l'approvatore finale avrebbe sotto gli occhi che chi ha approvato la richiesta è la persona stessa che l'ha fatta (o comunque un utente non qualificato).

Ovviamente tutto questo funziona perché il target del prodotto sono le aziende e gli enti di piccole o medie dimensioni.

Bye bye carta stampata.

Varianti

Il prodotto ha poi subìto un paio di evoluzioni che voglio solo accennare.

La prima (e più complessa): tramite il prodotto aggiuntivo auslfe.formonline.tokenaccess è possibile configurare il form in modo tale che

• l'utente che effettua la richiesta possa essere un utente anonimo
• l'approvatore della richiesta sia esso stesso un utente anonimo

Questo viene ottenuto inserendo nella mail inviata al responsabile uno speciale token segreto che fornisce temporaneamente i poteri di revisore all'utente.
Il token porta l'utente ad un form che permette di eseguire le azioni bi base sul modulo: approvare o rifiutare (magari con un commento alla modifica di workflow).

Tutto questo è possibile perché vengono sfruttate le funzionalità date da collective.powertoken.

La seconda variante è una semplificazione del workflow a tre stadi descritto sopra. Ci possono essere alcune procedure aziendali molto semplici dove non è richiesto che un proprio responsabile approvi la richiesta prima di sottoporla all'evasore finale.

I due workflow (standard e semplice) possono coesistere installando in Plone il supporto per le politiche di workflow (CMFPlacefulWorkflow).

Conclusione

Che sia questo prodotto o un altro, ci tenevo a mostrare come con Plone è possibile semplificare i flussi documentali del vostro Ente o della vostra Azienda.