1. Products.PloneBooking
2. rg.prenotazioni
3. seantis.reservation

presentati in rigoroso ordine di apparizione su pypi.

1. il redattore pubblica agende di risorse (ad es. prestazioni, servizi, sale...) con relative disponibilità
2. gli utenti richiedono la prenotazione della risorsa per un intervallo temporale
3. i gestori della risorsa trattano la richiesta di prenotazione.

Ma ora bando alle ciance e vediamo di conoscerli meglio.

Products.PloneBooking

Il "decano" dei prodotti per le prenotazioni è senza dubbio Products.PloneBooking. Nato per Plone 2, è ancora IL prodotto per le prenotazioni in Plone.

Lo sviluppo pare procedere lentamente: l’ultima release (3.0.0a2) è di un anno fa, ma fortunatamente su github si può trovare codice un po’ più aggiornato. Proprio questo codice è stato utilizzato per le prove di questo post.

Nonostante abbia utilizzato del codice di sviluppo di una versione alfa, non ho riscontrato nessun intoppo significativo nell’utilizzo del prodotto: per prenotare, prenota - e lo fa anche bene!

Il comportamento con javascript disabilitato non è impeccabile, ma nessuna delle funzionalità chiave è compromessa.

rg.prenotazioni

Questo prodotto è stato sviluppato nell’ambito dell’iniziativa PloneGov, inizialmente per Plone 3. Ultimamente, grazie a cekk e keul, è stato considerevolmente migliorato. Le nostre tartarughe l’hanno reso compatibile con Plone 4, non senza dimenticarsi di apportare notevoli migliorie al codice.

Il punto di forza di questo prodotto risiede nella possibilità di allocare a priori e con grande flessibilità intervalli di tempo per le prenotazioni e di specificare che, in determinate giornate, non verranno accettate prenotazioni (ad esempio durante le festività).

Il prodotto è completamente usabile pur disabilitando i javascript.

Il prodotto non è sicuramente maturo quanto PloneBooking e difetta della possibilità di avere una reportistica sulle prenotazioni, ma tale funzionalità è in via di sviluppo.

seantis.reservation

Questo prodotto è l’ultimo arrivato su pypi, e si vede! Non certo perché mostra difetti di gioventù (anzi, è proprio ben fatto) ma perché è il prodotto tecnologicamente più avanzato, sia per quanto riguarda l’interfaccia utente, davvero moderna, comoda e intuitiva, che per quanto riguarda la parte applicativa.

Proprio per questo il prodotto risulta installabile solo su siti Plone recenti (minimo 4.3), necessità di un server postgres di appoggio (minimo 9.1) e, per il suo utilizzo, richiede javascript.

Per quanto concerne le funzionalità, caratteristica distintiva di questo prodotto è la possibilità di poterlo configurare per permettere prenotazioni multiple nello stesso intervallo temporale.

E quindi?

Cosa dobbiamo usare? La risposta a questa domanda dipende molto dalle vostre effettive esigenze.

PloneBooking è consigliato se volete affidarvi a un prodotto maturo con una base di utenti consolidata; rg.prenotazioni è in fase di fervente sviluppo quindi aspettatevi a breve novità, correzioni e migliorie; seantis.reservation è quello che tecnologicamente cresce di una spanna su tutti, con vantaggi e svantaggi del caso.

Stiamo parlando infatti di tool molto potenti e raffinati, veri e propri "attrezzi del mestiere" di web developer e designer. 
Firebug, Chrome Developer Tools, Opera Dragonfly sono sicuramente tra i più diffusi e conosciuti, e offrono sofisticate funzionalità tra cui:

• debugger
• console JavaScript
• ispezione degli elementi DOM
• analisi dei log.

Problema

In ambiente mobile, nello sviluppo di applicazioni HTML5 (web app) le cose non sono diverse, nel senso che le esigenze sono le stesse dello sviluppo web tradizionale; a cambiare, però, sono gli strumenti disposizione.

I browser per mobile non hanno infatti le caratteristiche dei fratelli maggiori, lasciando così sviluppatori e designer sprovvisti di un vero e proprio "banco di lavoro" per le loro applicazioni.

Soluzione

Fortunatamente a venirci in soccorso sono proprio gli stessi ambienti di sviluppo desktop.mobile.
Negli ultimi anni infatti, alcuni di questi si sono evoluti aggiungendo funzionalità di remote debugging, come ha fatto per esempio Google per Chrome Developer Tools.

Il debug remoto permette di connettersi con il browser in utilizzo sul computer direttamente alla sessione attiva sul browser del dispositivo mobile e rende possibile interagire con essa in tempo reale.

Niente male, direi! Vediamo come si configura.

Installazione

Nativamente disponibile nella versione desktop di Chrome (F12 da tastiera), Chrome Developer Tools necessita di qualche componente aggiuntivo per l'utilizzo remoto.

Requisiti

• un dispositivo mobile Android
• l'ambiente di sviluppo Android (SDK)
• Chrome for mobile installato sul dispositivo
• un cavo USB

L'installazione dell'Android SDK non presenta grosse difficoltà in quanto Goolge fornisce direttamente l'installer per iOS, Linux e Windows. Una volta scaricato, vi basta seguire le indicazioni di configurazione fornite a schermo. Per maggiori informazioni trovate tutto qui.

Android SDK viene tipicamente usato per lo sviluppo di applicazioni native, ma è necessario anche nello sviluppo di applicazioni web mobile: infatti mette a disposizione adb (Android Debug Bridge) che permette la comunicazione tra il browser mobile attivo sul dispositivo e Chrome Developer Tools su desktop.

Chrome for mobile

Chrome for mobile è il browser di Google per mobile scaricabile free direttamente da Google Play. Attenzione ai requisiti minimi di installazione su Android: richiede infatti una versione 4 o superiore.

Configurazione

Finita la fase di installazione si può procedere con la configurazione, che in linea di massima dovrebbe essere molto veloce; bastano due flag selezionati nei punti giusti.

Ecco cosa fare: connettere il telefono al computer attraverso il cavo USB e, nell'ordine, abilitare il debugger usb in Android e il debugger web mobile in Chrome for mobile come mostrato di seguito:

Lanciare ora il comando adb direttamente da console per attivare la sincronizzazione tra desktop e dispositivo mobile:

adb forward tcp:9222 localabstract:chrome_devtools_remote

Fatto!

Utilizzo

Arrivati a questo punto abbiamo tutto il necessario per iniziare una nuova sessione di sviluppo. Digitare quindi nella barra degli indirizzi di Chrome l'indirizzo localhost:9222

Se tutto è andato a buon fine, quando si inizia la navigazione da cellulare dovrebbero comparire le pagine navigate in Google Chrome, come mostrato nell'esempio sopra, dove si vedono tre pagine da me aperte in quel momento. Ora potete scegliete quale ispezionare semplicemente cliccandoci sopra. Il sorgente sarà immediatamente disponibile in Chrome Developer Tools sul vostro computer, esattamente come fareste con le applicazioni per desktop:

Conclusioni

Nel difficile compito di ricerca delle performance, disporre di strumenti adeguati è molto importante specialmente per il mobile dove le risorse a disposizione sono (ancora) ridotte.
Chrome Deveveloper tools è uno di questi; di certo non può garantire che le vostre applicazioni siano di successo, ma è di grande aiuto affinché possano diventarlo.

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!

Alzi la mano chi ha sul muro dell'ufficio i segni inequivocabili di tazze, portapenne, robottini e cancelleria varia scagliati contro la personificazione di quel public.css di Sunburst che porta scolpito il blu #205C90 nei più reconditi recessi delle proprie righe.

Proprio così: il formato DTML è stato ufficialmente abbandonato e relegato alle versioni di Plone <= 3.x.

Attenzione: abbandonato non vuol dire "non supportato". Nei nostri temi basati su Sunburst possiamo tranquillamente introdurre file .dtml.
Allora non ci resta che prendere esempio dagli sceneggiatori di Beautiful e riportarli alla vita con un bel "coup de theatre".

Lo scopo di questo post non è di spiegarne l'uso, la sintassi o elencarne pregi o difetti. E' una scelta individuale e organizzativa che può essere o meno condivisibile. Ma per tutti i "plone-skinner" che la pensano come me, metto a disposizione la mia personale panacea:

• il buon vecchio base_properties.props, ampliato con ulteriori personalizzazioni (stili per la descrizione, bordo inferiore sui link, colore di hover sui link...)
• un file sunburst_public.css.dtml (da aggiungere al proprio tema) che fa uso del base_properties.props per ridefinire tutti gli stili (e solo quelli) del public.css di Sunburst in cui sia possibile sostituire un valore statico con una variabile dtml.

Entrambi i files vanno inseriti nella cartella "skins/miotema_styles" del proprio pacchetto. Il file sunburst_public.css.dtml dovrà essere registrato in profiles/default/cssregistry.xml con la classica direttiva:

<stylesheet id="sunburst_public.css" 
            media="screen" rel="stylesheet" 
            rendering="link"
            cacheable="True"
            compression="safe"
            cookable="True"
            enabled="1"
            expression=""/>

Consiglio di registrarlo prima del file css specifico del tema (esempio miotema.css).

Vantaggi?

Molteplici:

• cambiare faccia a Sunburst in 5 minuti
• evitare di sovrascrivere l'intero public.css
• ridurre gli episodi di ipertensione e nervosismo
• preservare il candore del muro del proprio ufficio.

Svantaggi?

Onestamente non ne vedo nessuno, salvo il fatto che il giorno in cui i dtml verranno definitivamente deprecati si dovrà necessariamente rivedere il proprio codice... ma in una simile circostanza si starà senz'altro procedendo con una migrazione di versione "major" e potreste sfruttare l'occasione per proporre un bel restyling del sito ;-)

Avvertenze e modalità d'uso: l'uso del prodotto può creare dipendenza e assuefazione. Assumere a piccole dosi e intervallare con la somministrazione di un tema Diazo per equilibrare i valori di "cssemia".

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.

E' per questo che spesso mi piace perdermi alla ricerca di qualcosa di nuovo da proporre. Qui sotto ho elencato una serie di slider e gallery costituiti principalmente da JQuery plugin e CSS3.

supersized! JQuery plugin

Supersized è un fullscreen background slideshow costruito utilizzando la libreria jQuery.

DEMO >>

SIDEWAYS

Una galleria fullscreen di immagini creata con la libreria jQuery e CSS. La galleria presenta le immagini a schermo intero in diverse modalità e con barre di scorrimento personalizzate.

DEMO >>

Flyout Image Slider Using jQuery & CSS3

Uno slider costituito da una pila di immagini, che funziona facendo “volare” l'immagine selezionata davanti alla pila. Usa le transizioni CSS3, animazione e jQuery.

DEMO >>

Rslider

Uno slider jQuery di immagini e contenuti, fullscreen e responsive.

DEMO >>

Portfolio Flipping Slider Using jQuery & CSS3

Uno slider per visualizzare il proprio portfolio con un effetto "flipping" per l'impaginazione. Usa jQuery e trasformazioni CSS3.

DEMO >>

Sequence

Uno slider responsive che usa transizioni CSS3 avanzate.

Sliding Horizontal Parallax Theme

DEMO >>

Apple iPhone4 Style Theme

DEMO >>

Minimalist Horizontal Sliding Theme

DEMO >>

Animated Responsive Image Grid

Un plugin jQuery per la creazione di una griglia di immagini responsive che cambia automaticamente le immagini con animazioni e tempi diversi.

DEMO >>

Showing Image With Bounce Effect

Un effetto di rimbalzo quando viene mostrata un'immagine, creato utilizzando trasformazioni CSS3 e animazione.

DEMO >>

Triple Panel Image Slider

Uno slider jQuery di immagini a pannello triplo con un look 3D.

DEMO >>

Minimit

Minimit Gallery è un plugin slider che supporta transizioni e trasformazioni CSS3, trascinamento, scroller, e interazioni touch.

DEMO >>

CSS3 Parallax scrolling slider

Uno slider verticale che usa solamente proprietà CSS3.

DEMO >>

Image Accordion with CSS3

Un accordion di immagini che espande un elemento al click.

DEMO >>

Vegas, Background jQuery Plugin

Uno slider di diversi background.

DEMO >>

Elastislide

Carousel responsive di immagini che si adatterà in modo fluido a un layout. Si tratta di un plugin per jQuery che può essere disposto in orizzontale o in verticale.

DEMO >>

Orbit, A Slick jQuery Image Slider Plugin

Un plugin jQuery per un slider di immagini.

DEMO >>

CSS-Only Responsive Layout with Smooth Transitions

Un layout con effetto a “scorrimento fluido” creato solamente attraverso CSS.

DEMO >>

Glisse.js

Un photo viewer jQuery, responsive e completamente personalizzabile.

DEMO >>

iosSlider, Touch Enabled jQuery Horizontal Slider Plugin

Un plugin jQuery progettato per essere usato come un dispositivo di scorrimento del contenuto, un carousel, un banner di scorrimento o una galleria di immagini.

DEMO >>

Elastic Image Slideshow with Thumbnail Preview

Uno slideshow "elastico" che usa miniature per le anteprime. La presentazione si regolerà automaticamente al suo contenitore.

DEMO >>

WOW Slider

Uno slider jQuery di immagini, responsive e con vari effetti di visualizzazione.

DEMO >>

Come vedete, le possibilità per mostrare le vostre immagini sono davvero molte; e queste sono solo alcune delle tante proposte!

Ci si potrebbe chiedere: "quale scegliere"? Ma a questa domanda non è possibile dare un risposta che vada bene per tutti. Alcuni di questi plugin richiedono funzionalità estremamente avanzate, non ancora disponibili per tutti i browser, e questo non è un aspetto che si possa trascurare. In altri casi potreste avere bisogno di una soluzione accessibile, e allora sarà vostro compito testare l'utilizzo della tastiera.

Una sola cosa credo sia chiara: le funzionalità che ad oggi CSS3 e HTML5 ci offrono, hanno reso più semplice la creazione di questi strumenti, e questo ci fa ben sperare per il futuro.

Spero che abbiate trovato in uno di questi slider una soluzione alla vostra specifica esigenza!

La foto in testata è di Widerbergs.

Nella vita di ogni sviluppatore arriva il giorno in cui si incrocia la propria tastiera con codice incomprensibile, dai risultati inspiegabili e che, ovviamente, bisogna correggere. Avere gli strumenti adatti per il debugging è fondamentale.

Come programmatore python ho avuto modo di utilizzare diversi tipi di debugger, dal semplice pdb a una versione più completa: pdb++. Esistono debugger integrati nei vari IDE di sviluppo, di cui però non ho mai approfondito troppo l'uso dal momento che li ho sempre trovato ambienti un po' pesanti. Da amante della shell, divido il mio tempo di sviluppo fra vim e un editor di testo molto semplice come sublime.

PuDB è un debugger visuale basato su Urwid. Quando ho visto la sua prima immagine ho pensato che fosse qualcosa per nostalgici: sono riaffiorati parecchi ricordi delle schermate che mi hanno accompagnato quando muovevo i primi passi con TurboPascal.

Ma questo effetto retrò è passato rapidamente in secondo piano: mi sono reso conto di avere sotto mano tutto quello che mi serviva per debuggare il problema su cui stavo lavorando.

Installazione e uso

L'installazione è semplice: è necessario utilizzare un interprete che vada almeno dalla versione 2.4 in poi, dopodiché, che si usi buildout, easy_install o pip per l'installazione è indifferente e in un attimo si è pronti all'uso del pacchetto; nel codice che si vuole debuggare basta inserire:

import pudb;pudb.set_trace()

e al momento dell'esecuzione, in shell ci si trova nel debugger:

Una sola immagine è già in grado di mostrare che si ha molto per le mani: un'intera pagina di codice sulla sinistra e 3 box sulla destra - il primo con le variabili dello scope, il secondo in cui viene mostrato lo stack e il terzo in cui si trova la lista dei breakpoint.

Caratteristiche principali

Il funzionamento base è come quello del pdb: 'n' per proseguire nel debug, 's' per entrare in un metodo e così via. Ma vediamo quali sono le caratteristiche principali di questo debugger e perché, secondo me, rende più veloce il debug.

Navigazione da tastiera tramite le frecce o Shift+[V/S/B] per passare ai box di variabili, stack e breakpoint

Prima di tutto, abbiamo un'ottima navigazione da tastiera: per chi è abituato a vim, si tratta di ricordare qualche combinazione o tasto in più, ma una volta memorizzati i comandi principali si va veramente veloci. Per una lista di tutti i comandi, si può fare riferimento alla guida inserita nel debugger stesso, attivabile premendo 'SHIFT+?'.

In secondo luogo, si vede una porzione molto ampia di codice; non è una regola, ma cerco di scrivere metodi non troppo lunghi (dove possibile) e con puDB diventa facile visualizzare l'intero metodo di cui si sta facendo debug.

Visualizzazione differenziata per le variabili (tipo, repr, str) ed espandibile nel caso di variabili complesse

Altra caratteristica che reputo importantissima (assieme alla visione completa del codice) è la presenza nei box di destra di tutte le variabili che vengono definite nello scope e aggiornate durante l'esecuzione. Quello che preferisco è il fatto che si possa agire in diversi modi sulle variabili: in caso di variabili complesse, queste si possano espandere come vediamo nell'immagine sotto (premendo '\'):

Inoltre si può scegliere il tipo di visualizzazione per ogni singola variabile, mostrandola per tipo ('t'), mostrandone la __repr__ ('r'), la __str__ ('s') oppure utilizzando una rappresentazione personalizzata ('c').

Stack delle chiamate navigabile

Per quello che riguarda lo stack, la possibilità di scorrerlo e di navigare nei metodi elencati al suo interno è molto utile, dal momento che si è in grado (senza dover aprire altre finestre o senza riavviare la sessione di debug) di visualizzare il codice chiamante dei metodi che stiamo analizzando. Una volta entrati in un altro metodo dello stack, cambierà lo scope e anche le variabili visualizzate saranno aggiornate; l'esecuzione del debug riprenderà da quel nuovo punto.

Ovviamente, nel caso fosse necessario utilizzare la linea di comando, la possibilità c'è: è sufficiente premere '!' per fare switch su una shell python contestualizzata nello scope corrente ('Ctrl-d' per uscirne).

Non c'è molto altro da aggiungere; la cosa migliore da fare è mettersi alla tastiera e iniziare a utilizzare questo debugger!

Immagine nel body: http://www.flickr.com/photos/smitty/2245445147/

Immagine in testata: http://www.flickr.com/photos/28208534@N07/4047355843

Ciao, ho sottomesso per la pubblicazione questo post:
- http://blog.redturtle.it/migrating-dexterity-items-to-dexterity-containers

Vi avviso che è di una noia mortale: già dopo 10 righe capirete che è un'impresa inutile andare avanti. Chi di voi desiderasse avventurarsi oltre sappia che rischia di essere preda di attacchi convulsivi da far invidia a quelli del principe Myskin.
Però, secondo me, l'argomento è interessante e mi permette di confrontarmi con i guru di Plone.

Giuro che la prossima volta:
- scrivo in itagliano scorrente
- scrivo di bagigie

Mi sono impegnato molto nel tentare di non subire le dure stoccate di te, cara signorina social: spero di aver fatto tutto a dovere (immagini, page break, numero caratteri, doccia e bidet).

Ciao!

P.s.: il prossimo blog post sarà un copia incolla di questa mail.

Tutto potrebbe finire qui, ma voglio rivelarvi alcuni dei terribili e inconfessabili segreti che si celano dietro le righe dei nostri allegri post.

Innanzi tutto, il fatto stesso che ci siano dei revisori è un indice di come le vostre tartarughe preferite non lascino nulla al caso. Ben sapendo quanto sia importante il social media marketing, abbiamo costituito al nostro interno una task force che si occupa di curare la nostra (e quella dei nostri clienti) presenza sul web.

Questi "mostri spaziali", come dicevo nell'abstract, si assicurano che chi realizza i vostri siti non si limiti a destreggiarsi nelle nuvole di bit, ma si conceda saltuariamente divagazioni letterarie, impreziosendo il proprio lavoro con pregevoli citazioni allo stupendo principe Myskin, protagonista dell'Idiota di Dostoevskij.

Dietro a questi nobili intenti si celano retroscena raccapriccianti. Funziona così: a intervalli regolari una tartaruga ignara viene presa, incappucciata e tratta in una cantina buia dove deve redigere in un minuto e mezzo un blog post.

Gli argomenti dei post sono in gran parte lasciati alla buona volontà degli autori, i quali cominciano a sudare freddo, ben sapendo che se sbaglieranno tema i loro carapaci verranno segnati per la vita con fruste infuocate.

Stante il fatto che questo è il blog di un'azienda che "lavora il web", ovviamente non è sensato parlare di bagigie (ovviamente!), ma è anche meglio evitare contenuti troppo tecnici. Purtoppo, avendo trasgredito l'ultima volta scrivendo un post iper tecnico, sono stato costretto a cadere nell'estremo opposto scrivendo di bagigie, operazione che mi causerà una doppia razione di scudiscio.

Dopo che il tema del post è stato considerato meritevole di pubblicazione, la povera tartaruga è ben consapevole di dover ornare il suo post con immagini, frasi e metadati destinati all'integrazione con i social network.

Per esempio ogni post ha una immagine in testata, che vedete sulla pagina del post, ma ha anche un'immagine (più squadrata) dedicata a Facebook. Anche le lunghezze dei testi sono studiate per integrarsi al meglio con i social network, ad esempio Twitter.

Deputata a sincerarsi che tutte queste accortezze siano rispettate e che i nostri articoli siano comprensibili e scritti in "itagliano scorrente", è la figura oscura della "signorina social". Nessuno sa veramente chi sia e se esista per davvero, ma si vocifera che si aggiri nella notte a caccia di errori di ortografia, causando ai loro autori la morte tra atroci sofferenze.

Se la tartaruga sopravvive a tutto questo, il suo post viene pubblicato e può tornare a programmare alla sua scrivania (sempre che qualche sciacallo nel frattempo non abbia saccheggiato il saccheggiabile).

Gioite quindi, adorati lettori, alla vista di un nuovo post su questo blog: finché i vostri occhi leggeranno le nostre parole, noi saremo in vita. E soprattutto condividete la vostra gioia con il mondo: cinguettateci, piaceteci, incrementateci, pinteressatevi di noi!

A presto! (forse...)

Originale immagine in testata: http://www.flickr.com/photos/teresahsu/6410106143/sizes/l/in/photostream/

Scheletro tartaruga: http://upload.wikimedia.org/wikipedia/commons/9/9a/Galapagos_Turtle_skeleton.jpg

Cesare in vacanza: http://fc06.deviantart.net/fs8/i/2005/314/6/7/Alien_Tourist_by_madart84.jpg

P.s: i bottoni per cinguettarci, piacerci, incrementarci, pinteressarci sono là sopra!

P.p.s: chi mi ha fregato la sedia intanto che ero via?

P.p.p.s: Il mio preferito è Woodstock

P.p.p.p.s: Grazie a Baio per il suggerimento degli Skiantos e a Cekk per la foto imbagigiata

________

Visto, approvato e pubblicato dalla "signorina social" in data odierna, con 3 tratti di matita rossa soltanto.

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.

Perché Bootstrap?

Perché fornisce una solida base di partenza per il templating, dispone di una vasta scelta di effetti javascript integrati, rende più semplice l'approccio al responsive (adattare la visualizzazione alle diverse risoluzioni) e, se usato nella versione sorgente, permette la massima personalizzazione grazie a Less.

Le dosi

Per avere la giusta lievitazione dell'impasto è necessario includere tutti i sorgenti di Bootstrap senza modifiche: si potrà in futuro aggiornarli alle ultime versioni disponibili senza correre il rischio di perdere le proprie personalizzazioni.

Nel file "core" del progetto (nel mio caso sternweber.less) sarà sufficiente iniziare con:

@import "../bootstrap/less/bootstrap.less";

bootstrap.less includerà a sua volta tutti i file originali del framework.

Si procede poi ad amalgamare gli ingredienti aggiungendo:

@import "variables.less"; 
@import "mixins.less"; 
@import "plonemixins.less";

dove

• variable.less permette non solo di dichiarare le proprie variabili ma anche di ridefinire quelle di Bootstrap (colori, font, dimensioni, ...)
• mixins.less aggiunge alcune utilissime funzioni a quelle già presenti in ../bootstrap/less/mixins.less: se siete frontend developer e non avete mai provato Less o Sass allora... sorridete! Siete su Cucine da incubo ;-)
• plonemixins.less, per la gestione di alcune parti di html specifiche sfornate da Plone, mi è stato saggiamente consigliato da Denys in occasione dei training 2012: posso dire senza sbagliare che è stato il Gordon Ramsey della situazione!

Tutto il resto è olio di gomito e una lenta cottura alla giusta temperatura.

Perché Diazo?

Per avere tanta autonomia e flessibilità in frontend quanto Plone la permette nel backend. I gestori del sito hanno largamente apprezzato i vantaggi di un'area redazionale semplice, leggera e veloce e non hanno trovato limitante verificare la resa grafica delle pagine in un frontend separato.

Diazo, ormai integrato nelle ultime versioni del CMS pythonico, può fare la differenza tra un'ottima ciambella ricoperta di zucchero a velo e una torta da competizione come solo Buddy sa sfornare: alzi la mano il web designer a cui non sia mai stato chiesto "vorrei una torta multistrato, a più piani, magari a forma di brontosauro ma devi arrangiarti con uno stampo tondo con il buco"!

Perché Plone?

Ma dai... è una cosa da chiedere? ;-)

Credits photo

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.

Il Buildout 2.0 fa un taglio netto con il passato che, con le versioni 1.6 e 1.7, aveva come obiettivo principale quello di isolare il più possibile il buildout dalla componente Python. Ma il compito si è rivelato troppo difficile da implementare, e quindi si è scelto di abbandonare questa strada e lasciare all’utilizzatore di decidere tramite l'utilizzo di virtualenv.

Non è però in questo articolo che voglio analizzare le modifiche apportate a questo componente (che potete comunque trovare qui). Oggi vediamo cosa fare per far funzionare i nostri bulidout.

Rimanere ancorati al passato.

Tutto dipende dal bootstrap.py presente nel vostro buildout.

Se vi interessa rimanere sulle versioni 1.x, allora potete usare questo bootstrap.py: contiene una restrizione sulla versione di zc.buildout che deve essere minore di 2.0 - http://downloads.buildout.org/1/bootstrap.py.

Ma se non vi sentite troppo sicuri nel sostituire il bootstrap.py del vostro buildout, c’è una seconda soluzione, suggerita in risposta a questo bug report su stack overflow.
Dovrete semplicemente rilanciare il bootstrap del vostro buildout forzando la versione di zc.buildout in questo modo:

     python bootstrap.py -v 1.7.1
 

Tuttavia, con versioni molto vecchie del bootstrap.py, potreste ritrovarvi nel caso in cui non sia possibile forzare la versione; allora dovrete per forza aggiornare il file con la versione di cui sopra, per poi eseguire il comando forzando zc.buildout all’ultima versione precedente alla 2.0; al momento, questa: https://pypi.python.org/pypi/zc.buildout/1.7.1.

Il nuovo che avanza.

Per usare la versione 2.0 di zc.buildout vi consiglio di utilizzare questa versione del bootstrap: http://downloads.buildout.org/2/bootstrap.py.

In questo caso, però, vi potreste trovare nella situazione inversa, ovvero: dopo aver lanciato il solito comando "./bin/buildout -N", non trovate la nuova versione di zc.buildout.

La causa è da attribuire alla presenza di buildout.dumppickedversions che ha fatto il pin di alcune versioni e, quindi, lanciando il buildout con il “-N” (pratica più che corretta!), la nuova versione per zc.buildout non è stata presa in considerazione.
Magari avete specificato il dumppickedversions nelle extensions nel vostro buildout.cfg e state pensando di rimuoverlo; ma nelle ultime versioni del buildout è automaticamente incluso.
La soluzione, consigliata da Reinout van Rees nel suo post, è molto semplice: fate il pin di questi due prodotti nel [versions] del vostro file di configurazione e avrete il vostro pacchetto aggiornato :)

    [versions]
    zc.buildout = 2.0.1
    zc.recipe.egg = 2.0.0a3
 

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