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!

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.

Per esempio, se un informatico (uno a caso) ha la passione per il fantacalcio e deve pensare a come gestire l’asta che si svolgerà a settembre con i suoi amici, questa è l’occasione giusta per sperimentare qualche nuova tecnologia per creare un’applicazione che li aiuti.

Quale tecnologia adottare?

Il primo passo ovviamente è stata la scelta della tecnologia da utilizzare. I requisiti erano molto basilari (stiamo pur sempre parlando di uno svago): un’applicazione semplice e leggera che permetta di memorizzare in un database una serie di informazioni, eseguire diverse query e inserimenti successivi.

Plone non era lo strumento giusto, volevo sperimentare!

Idea che ho scartato quasi subito: lavorandoci quotidianamente, so che non mi sarebbe servito un sistema così grande e complesso. E poi, che esperimento sarebbe stato, giocando in casa? ;-)

Mi sono messo allora a cercare informazioni su altri framework basati su python: va bene sperimentare, ma mantenendo qualche sicurezza nello sviluppo dell'applicazione. Stavo pensando a Django e Pyramid (già usati per diversi progetti in azienda, ma su cui non ho ancora avuto la fortuna di lavorare), quando sono stato introdotto a un sistema che non conoscevo. Mentre a Firenze si svolgeva Europython, in rete fioccavano tweet su un talk di Nicola Iarocci incentrato sul framework Flask.

Subito incuriosito, sono andato a cercare più informazioni in merito. Sul sito ufficiale viene descritto come un “microframework for Python based on Werkzeug, Jinja 2 and good intentions”. In sostanza, il framework si basa su un’applicazione centrale, la quale ha il compito di smistare le varie richieste che arrivano verso diverse funzionalità precedentemente definite.

Questo si nota bene dal primo semplice esempio che ho trovato sul sito:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run()

Non si fa altro che creare una nuova app e si imposta in modo che tutte le richieste che arrivano sulla porta in cui è in ascolto visualizzeranno il classico “Hello world!”.

La documentazione sul sito è molto ben fatta; c'è anche un tutorial molto chiaro, che permette di prendere subito confidenza con le funzionalità principali del framework, tra cui un ottimo e intuitivo motore di templating (Jinja2) e gli immancabili test.

Visto che uno dei miei prerequisiti era proprio quello di creare un’applicazione snella e con poco sforzo, ho deciso di buttarmi su Flask.

Il problema successivo è stato scegliere come e dove memorizzare i dati. Il tutorial ufficiale utilizza un semplice database SQLite per creare un microblog. Poteva anche andarmi bene visto che non avevo particolari esigenze, però guardando le slide del talk di Europython e cercando in rete, ho trovato diversi esempi di integrazione di Flask con database NoSQL, come MongoDb e Redis.

Perché non provare anche un nuovo tipo di database, già che c’ero? La scelta è ricaduta su MongoDB, il quale ha una gestione del database a Documenti e ovviamente ha una serie di librerie specifiche per i più famosi linguaggi di programmazione. Io ho optato per MongoEngine perché è dotato di una buona documentazione e permette di integrarsi facilmente con un database MongoDB.

Come ultimo passo ho utilizzato il famoso TwitterBootstrap per avere un’ottima base grafica di partenza.

Non mi soffermo su come ho implementato la mia applicazione, anche perché è ancora in fase di sviluppo. Passo invece esporvi le mie considerazioni su Flask, che sono decisamente positive.

Flask è semplice e potente

In poco tempo si riesce a mettere in piedi un sistema completo e funzionante grazie alla semplicità della sintassi e alla potenza degli strumenti che mette a disposizione, come il motore di templating e la possibilità di avviare il server in debug-mode per lo sviluppo. Questo è davvero utile perché permette di avere un traceback immediato di eventuali errori, senza dover riavviare a ogni cambiamento.

Ovviamente di base non offre molti strumenti a parte il routing delle richieste e la gestione delle viste, però come tutti i progetti open-source che si rispetti ha una buona comunità che ha già prodotto diversi plugin per aumentare le sue funzionalità. Tra queste, la gestione delle sessioni degli utenti, la connessione a diversi database, l’internazionalizzazione o la possibilità di generare form automaticamente con WTForms.

Potrebbe quindi essere un valido strumento alternativo a Django o a Pyramid nella costruzione di applicazioni web dove serve un certo grado di personalizzazione e non si ha bisogno di framework più strutturati, come ad esempio Plone.

Partiamo da un po' più lontano; mai visto questa schermata?

Beh, suppongo proprio di sì. Questo è dovuto al controllo di integrità referenziale che ha trovato un problema; cancellando Pagina 2, il link contenuto in Pagina di Test risulterà rotto, senza più il suo riferimento.

   parent.manage_delObject(obj_id,)
 

Ve lo dico io. Il controllo in questione si attiva ugualmente e vi impedisce di cancellare l'elemento, ritornando un'eccezione (LinkIntegrityNotificationException). Forse anche questa cosa vi era nota e magari nelle vostre pocedure, essendo previdenti, gestite l’eccezione in un modo simile a questo.

   try:
       parent.manage_delObject(obj.getId())
   except LinkIntegrityNotificationException:
       custom_log(“Non è stato possiblie cancellare il contenuto %s a causa di un problema 
                   di integrità dei link” %obj.absolute_url())

Non crediate di essere al sicuro perché, nel caso in cui la procedura debba cancellare più di un documento, potreste incappare in un comportamento anomalo:

Invece di cancellare tutte le schede tranne quelle per cui si è trovata l’eccezione di integrità dei link, ci si ritrova che nessuna delle schede che si voleva cancellare viene cancellata.

Mi sono imbattuto in un caso del genere mentre sviluppavo una procedura per permettere la sincronizzazione di contenuti Plone su portali differenti. La procedura aveva tre fasi: aggiunta di nuovi contenuti, modifica dei contenuti già esistenti e cancellazione dei contenuti non più presenti sul portale di origine.

Il portale di destinazione però non era totalmente sotto il controllo della sincronizzazione e quindi poteva capitare che altri contenuti del portale avessero un link che puntava a una scheda che doveva essere cancellata.

Scoperto il problema, mi sono messo ad analizzarlo e ho scoperto che la causa di questa anomalia è da imputare al pacchetto plone.app.linkintegrity e più precisamente alla creazione dell’istanza della classe LinkIntegrityInfo.

Alla classe LinkIntegrityInfo è demandato il compito di salvare gli errori di integrità referenziale durante la procedura di cancellazione, per poi notificarli all’utente tramite la schermata mostrata all'inizio.

Purtroppo questa classe viene inizializzata tramite un unico parametro: context, che è la request dell’azione.

   def __init__(self, context):
       self.context = context      # the context is the request
 

Nel caso si sia lanciata una procedura che deve cancellare una serie di contenuti, la request è sempre la stessa e quindi per ogni contenuto che si cerca di cancellare Plone va ad analizzare la stessa istanza di questa classe.

I metodi di controllo che vengono richiamati durante la cancellazione, però, ritornano l’errore di integrità referenziale non solo se il contenuto che si sta analizzando ha questo tipo di problema:  succede anche se c’è già salvato un precedente contenuto contenente un link che aveva questa problematica.

   def getIntegrityBreaches(self):
       """ return stored information regarding link integrity breaches
           after removing circular references, confirmed items etc """
       deleted = self.getDeletedItems()
       breaches = dict(self.getIntegrityInfo().get('breaches', {}))
       targets = breaches.keys()
       for target, sources in breaches.items():    # first remove deleted sources
           for source in list(sources):
               if source in targets or source in deleted:
                   sources.remove(source)
       for target, sources in breaches.items():    # then remove "empty" targets
           if not sources or self.isConfirmedItem(target):
               del breaches[target]
       return breaches
 

Se non volete stare ad impazzire facendo patch su patch di queste funzioni io vi propongo una soluzione tanto semplice quanto efficace:

Mentre scrivete la vostra procedura di cancellazione ricordatevi di effettuare dei controlli preventivi.

Per ogni elemento potrete eseguire il controllo riportato nel box sotto e fare la cancellazione solo quando sarete sicuri che non verrà rilevato un errore di integrità referenziale; in caso contrario eseguite il log dell’errore.

   rc = getToolByName(self, 'reference_catalog')
   for obj in to_delete_obj:
     back_references = rc.getBackReferences(obj, relationship="isReferencing")
     if not back_references == []:
       for back_ref in back_references:
         errorlog('Errore durante la cancellazione; l’oggetto è referenziato da: %s'
                  %'/'.join(back_ref.getSourceObject().getPhysicalPath()))
     else:
       try:
         obj.aq_parent.manage_delObjects(obj.id)
         transaction.commit()
 

Sicuramente questa non è l'unica soluzione al problema, ma mi ha consentito di aggirare velocemente l'ostacolo e di procedere con successo.

Perciò mi sento di consigliarvi di  mettere in conto questo tipo di controllo ogni qual volta avrete a che fare con una procedura di cancellazione. Questo vi permetterà di evitare di inserire debito tecnico nel codice,si ridurrà la probabilità di dover eseguire bug fixing e quindi, cosa più importante, vi farà risparmiare tempo e denaro.

Check the site: www.facciamoadesso.it

Plone

Most of the application is done in Plone, which is so fast to develop nowadays. We have used heavily eea.facetednavigation which saved us hours if not days. Big thanks to Alin Voinea, Alexandru Ghica, Antonio De Marinis. You guys rock!

We have implemented a custom facebook integration with a separate PAS plugin. We couldn't use plonesocial.auth.rpx cause we wanted to integrate more deeply with facebook app (more about that later), and that will cost a fortune using rpxnow.com.

We have also added a small disqus trick that notifies archetype object owner that somebody made a comment. We are using the callback method:

 function disqus_config() {
    this.callbacks.onNewComment = [function(comment) {
         $.post('%(document_url)s/disqus_notify', {comment: comment});
       }];
  }
 

 class Notify(BrowserView):
     def __call__(self):
         comment_text = self.request.form.get('comment[text]')
         comment_id = self.request.form.get('comment[id]')
         objectEventNotify(DisqusNotify(self.context, comment_id, comment_text))
 

you can find a working example on github.

We have also a separate Zope process that is collecting internal stats (products sold, value gained, etc.) mounted in a separate ZODB. In this case we have minimized the problem of ConflictErrors while having the stats always fresh.

pyramid / celery

Second important part of the project is the notification app. We are notifying users almost on every single user action (registration, creating company, adding products, buying, commenting, etc.). We are sending 3 types of notifications: email, sms and facebook (using open graph API). We wanted to have something async, easy to implement and stable. Pyramid_celery was the best choice.

Facebook and Open Graph

Last important part of the stack is the facebook integration. We wanted something more then simple authentication. We wanted to involved facebook users a bit more. Thanks to Open Graph it's quite easy.

First we have included the basic og meta tags in your <head> section. We have used an existing Plone product for that. Then we have registered several actions, objects and aggregations that correspondent to notifications I have mentioned before.

One of the action we have is sell. It can be used only with product object. In Plone you need to include in the <head> section of your product object additional meta:

 <meta property="og:type" content="facciamoadesso:product" />
 

and then using your new action is trivial:

 curl -F 'product=http://example.com/products/my-product' \
      'https://graph.facebook.com/me/facciamoadesso:sell'
 

and that's it. Well, almost. You need of course to handle the access_token (we did it with our custom PAS plugin explained above).

Once again many thanks to all Plone and pyramid developers whose add-ons we have used! It's truly amazing how much you can get in such a short time period.

Last, some code stats:

• 21.274 lines of code
• 4 contributors
• 127 tickets closed
• Most productive between 12:00-13:00 :-)

All the code is open source and can be found on RedTurtle's github repository

E ora bando alle ciance, mettiamoci a parlare del prodotto di oggi:

PloneGazette

L’AT principale è “NewsletterTheme”; esso è considerato un canale di newsletter e quindi per ognuno degli elementi è possibile configurare la solita serie di campi obbligatori come titolo, email di test, email del mittente, formato con cui inviare, ecc. e una serie di dati che ci permettono di configurare le mail che vengono inviate come più ci piace.
All’interno di un “NewsletterTheme” si possono aggiungere “Newsletter Large Folder”, “Newsletter” e “Subscriber”.

Gli oggetti “Subscriber” sono molto semplici e permettono di scegliere la modalità di invio della mail, testuale o html. I gestori della newsletter che registrano un utente tramite il menu di aggiunta classico, hanno anche la possibilità di attivare direttamente l’iscritto.

La “Newsletter Large Folder” serve per la visualizzazione e la gestione dei subscriber; la vista associata a questa cartella mostra in una tabella l’elenco degli iscritti alla newsletter. Vi è indicato, per ogni utente, il formato con cui vuole ricevere la newsletter e lo stato di attivazione. I gestori della newsletter potranno, da questa vista, eliminare subscriber.
Le singole mail sono gestite tramite gli oggetti “Newsletter” in cui si inserisce titolo, descrizione e testo.

Questo prodotto ci consente una grande personalizzazione del template della mail oltre alle più comuni personalizzazioni quali header, footer e css. Permette di usare una sintassi TAL per richiamare un template, precedentemente creato e caricato nel portale, ed utilizzarlo come render per la mail che viene spedita.

La cosa è sicuramente apprezzabile da parte dei programmatori, che possono così mettere mano su tutti gli aspetti della resa grafica. Il dettaglio della singola newsletter presenta un utile tab (Test) che permette di avere la preview di entrambi i tipi di mail (plain text e html) oltre al solito invio di test all’indirizzo impostato. Questa è un’ottima funzionalità vista anche la possibilità di una forte personalizzazione del template della mail.

La portlet di iscrizione ai canali per gli utenti anonimi è completa: oltre ai due campi proposti anche nel form di iscrizione, mostra all’utente i vari canali a cui è abilitato ad iscriversi. Contiene inoltre una serie di link ad ognuno degli archivi per consultare le newsletter passate.

Cosa non ci piace

Se i programmatori apprezzeranno l’idea di personalizzare tramite TAL il template di render della mail, per gli utenti, più o meno esperti, questa possibiltià non è propriamente fruibile. Gli utenti poco esperti, che devono configurare una newsletter molto base, si trovano alcuni campi di troppo che non sanno se e come configurare, mentre utenti un po’ più esperti devono agire via ZMI per creare il loro template. Creando un oggetto Plone “ATTemplate” si sarebbero potuti migliorare entrambi gli use case.

La gestione della folder per i “Subscriber” non è molto chiara, poiché inizialmente alla creazione di una “NewsletterTheme” non viene creato alcunché. Bisogna procedere in un secondo momento a creare a mano un “Newsletter Large Folder” e poi rientrare in modifica del “NewsletterTheme” a settare l’id della cartella appena creata. Questo passaggio ci è sembrato inutile ed automatizzabile.

L’iscrizione alle newsletter, che possono effettuare gli utenti Plone tramite il tab presente nella barra di “gestione” del “NewsletterTheme”, non propone la mail utilizzata durante la profilazione del proprio account. Anche la creazione della portlet per la registrazione di utenti anonimi è una procedura abbastanza macchinosa, ma questo è probabilmente dettato dal fatto che il prodotto viene da una vecchia versione di Plone.

Oltre l’orizzonte

E' giunto per noi il momento di tirare le somme di tutto ciò che abbiamo scritto: 
Singing&Dancing, trattato nella prima parte, EasyNewsletter, di cui abbiamo parlato nella seconda parte, PloneGazette, discusso in questo articolo, o qualcosa di diverso che tratteremo in un quarto capitolo?

PloneGazette è stato, ultimamente, rilasciato per Plone 4 ma lo sviluppo sembra abbandonato e quindi non ci sembra, al momento, una scelta possibile per il futuro.

Noi usiamo con moderato successo sia Singing&Dancing che EasyNewsletter e quindi consigliamo di concentrarsi su questi due prodotti.

Ci sembra evidente che EasyNewsletter ha bisogno di lavoro per chiudere i bug noti e consolidare tutto il pacchetto, mentre Singing&Dancing ha già un buon grado di solidità ed è ben seguito dalla comunità.
La nostra esperienza ci porta quindi a propendere per l’utilizzo di Singing&Dancing (anche se non è esente da difetti, come abbiamo visto) ma aspettiamo con ansia la ripresa di EasyNewsletter così da proporre una bella sfida, come è giusto che sia in un ambiente OpenSource.

Esiste certo un’altra via per gestire le newsletter; ovvero quella di appoggiarsi a servizi esterni (come MailChimp per esempio), soprattutto se si prevede un intenso traffico di iscrizioni alla newsletter e di messaggi spediti.
In questo modo si può alleggerire il sistema (sia in termine di banda che di prestazioni, visto che Plone non dovrà prendersi carico anche della spedizione di migliaia di mail, ma potrà tornare ad occuparsi solo della gestione del portale) e delegare la gestione delle newsletter esternamente. In questo modo il programmatore dovrà solamente preoccuparsi di come interfacciare Plone con questi servizi, per esempio fornendo strumenti per potersi iscrivere direttamente alle newsletter dal sito.
E per il gestore del portale? Cambierebbe qualcosa?
Forse sì, dato che la gestione del sistema di newsletter potrebbe non risiedere più solo in un posto (Plone) ma potrebbe essere necessario fare certe configurazioni nel proprio portale e altre all’interno del servizio esterno che si sta utilizzando.
Infine, ciò potrebbe portare a una maggiore manutenzione da parte delle aziende sviluppatrici che si potrebbero trovare a convivere, analizzare, segnalare problematiche legate al sistema esterno di mailing senza poterli risolvere direttamente.

Ci sono state, in tempi più o meno recenti, discussioni a riguardo; ma probabilmente non sono state risolutive. L’argomento ci sembra abbastanza importante per la completezza di un CMS come Plone e pensiamo che l’argomento newsletter potrebbe essere portato a una discussione più ampia all’interno della comunità, cercando di trovare una direzione comune e di avere un buon prodotto completo ed affidabile.

Cosa deve esserci

Continuiamo il nostro viaggio nel mondo delle Newsletter iniziato nella prima parte con l'analisi di Singing & Dancing.
Oggi prendiamo in esame un secondo prodotto che abbiamo utilizzato in diverse occasioni:

EasyNewsletter

nome prodotto: Products.EasyNewsletter
mantainer: Maik Derstappen
pagina ufficiale: http://plone.org/products/easynewsletter

Il pacchetto Products.EasyNewsletter si compone di 4 AT: “Newsletter”, “Issue”, “Subscriber” e “Template”.

L’oggetto “Newsletter” costituisce il canale, riguardante un determinato argomento o per una determinata zona del portale; gli oggetti “Issue” sono le singole mail che potranno essere inviate; “Subscriber” è un oggetto che identifica il singolo utente, non Plone, registrato al canale che riceverà le issue di notifica; “Template” è un AT per definire la resa grafica della parte di contenuto delle issue.



Infine è disponibile una portlet che permette la sottoscrizione ad un canale da parte di utenti anonimi andando a creare un subscriber.

Cosa ci piace

Sicuramente ci ha colpito la grande flessibilità nella gestione del templating che è configurabile sul singolo oggetto “Newsletter”. Questo permette di avere configurazioni indipendenti per ogni newsletter creata nel portale.

L’impostazione di header e footer viene effettuata tramite dei RichWidget, sia a livello di newsletter sia a livello delle singole issue, andando in questo caso a sovrascrivere le impostazioni definite a livello newsletter; è quindi facile per l’utente inserire testo formattato o immagini.

A livello di newsletter, invece, è possibile modificare aspetti come i CSS da applicare alle mail da spedire, inserendo stili che rendono personalizzabili le newsletter le une dalle altre; a seconda della sezione, si può avere una mail con sfondo bianco, giallo o nero.

La possibilità di scegliere una serie di gruppi o singoli utenti ci è sembrata molto utile per gestire più newsletter nello stesso portale; se si pensa, per esempio, ad un portale medico dove possiamo avere una decina di branche specialistiche, ognuna con il proprio gruppo (di soli lettori o redattori), ecco che usando una newsletter per ogni specializzazione si può facilmente provvedere all’invio solo alle persone interessate tramite la configurazione del gruppo a cui inviare.

Cosa non ci piace

Gli AT “Newsletter” e “Issue” sono stati creati come estensione degli oggetti “Collezione” e questo, secondo noi, porta più svantaggi che vantaggi.

Gli svantaggi riguardano soprattutto l’usabilità per un utente redattore che, seppur conoscendo l’ambiente Plone ed il comportamento delle collezioni, potrebbe trovarsi in difficoltà a gestire criteri e sotto-criteri.

Sia l’oggetto “Newsletter” che i singoli oggetti “Issue” hanno a disposizione il tab “Criteri” e “Cercatori subordinati”, che sono da comandare attraverso la creazione di AT “Template” o della modifica del template di default. Per impostare la resa grafica della issue si hanno quindi quattro elementi principali: il testo che si va a scrivere nella issue; i file eventualmente contenuti all’interno dell’oggetto “Issue”; i risultati secondo i criteri della issue; i risultati secondo i criteri degli eventuali cercatori subordinati.

Il testo che si inserisce nella issue deve essere sempre visibile, mentre l’elenco dei risultati del cercatore e dei sotto-cercatori sono opzionali. A complicare la situazione intervengono il cercatore della newsletter e i suoi sotto-cercatori, i quali compaiono se non sovrascritti da cercatore e sotto-cercatori delle singole issue.

<tal:block tal:repeat="object context/queryCatalog">
    <h1 tal:content="object/Title">Title</h1>
    <p>
        <span tal:content="object/Description">Description</span>
    </p>
    <p>
        <a tal:attributes="href object/getURL">Please read on.</a>
    </p>
</tal:block>

<tal:block tal:repeat="subtopic context/getSubTopics">
    <h1 tal:content="subtopic/Title">Title</h1>

    <tal:block tal:repeat="object subtopic/queryCatalog">
        <h2 tal:content="object/Title">Title</h2>

        <p>
            <span tal:content="object/Description">Description</span>
        </p>
        <p>
            <a tal:attributes="href object/getURL">Please read on.</a>
        </p>
    </tal:block>
</tal:block>

A noi questa gestione non è piaciuta perché ci pare più frequente la possibilità di avere delle issue contenente un semplice testo piuttosto che un elenco di una collezione.
L’invio di una issue contenente i risultati di una collezione poteva essere risolta molto più facilmente creando un adapter per ENL, che sfruttasse il sistema del template per il contenuto, come abbiamo poi creato noi con la nostra estensione descritta sotto.

Estensioni: EasyNewsletterSendTo

Questa estensione che abbiamo sviluppato, ma non ancora rilasciato, è nata da un’idea molto semplice:

la maggior parte delle volte un redattore vuole inviare un contenuto del sito come newsletter invece di dover riscrivere informazioni su un evento o una notizia

Per questo motivo abbiamo pensato che sarebbe stato utile studiare un modo per creare un oggetto “Issue” a partire dalle informazioni presenti nei vari AT Plone.
Abbiamo per questo sviluppato una nuova action “Send to Newsletter” che permette ad un redattore di creare una issue in una o più newsletter nelle quali ha il permesso di operare.
La cosa più importante è il mapping dei campi dei vari AT Plone con quelli disponibili nell’AT “Issue” fatto tramite una serie di adapter; l’esempio sotto si riferisce a due funzioni usate per l’inserimento di un AT “Image” dentro il campo testuale della “Issue” .

def contentToDict(self):
    ''' Returns a dictionary with some field of the object '''
    kargs = {}
    kargs['title'] = self.context.Title()
    kargs['description'] = self.context.Description()
    kargs['text'] = self.manageText()
    kargs['text_text_format'] = 'text/x-html-safe'
    return kargs

def manageText(self):
    ''' aggregator of some field into text '''
    return '<p><img title="%s" alt="%s" src="%s" /></p>' %(self.context.Title(),
             self.context.Title(),
             self.context.absolute_url()+'/image_preview')

Un esempio, invece, di caso più particolare è quello dell’invito dell’AT “Topic” per cui abbiamo deciso di non andare a complicarci il lavoro cercando di inserire la vista delle collezioni dentro il campo di testo della issue; abbiamo invece sfruttato la possibilità di avere sotto-collezioni andando a copiare la collezione come oggetto figlio della issue (in questo caso diventa una sotto-collezione).
Per essere certi della resa grafica siamo anche andati ad utilizzare un nuovo template, inserito nel nostro pacchetto aggiuntivo, che mostra soltanto l’elenco delle sotto-collezioni in modo simile alla vista delle collezioni Plone.

Il tutto è corredato dalle possibilità di inviare il contenuto tramite più newsletter e di aggiungere un prologo, che viene utilizzato come descrizione all’inizio della mail generata.
Per il futuro pensavamo di migliorare questa estensione inserendo anche un’anteprima delle varie mail generate mostrando soprattutto la resa grafica, probabilmente differente, dovuta alle diverse personalizzazioni realizzate nelle varie newsletter.

To be continued...

Per quanto riguarda la nostra esperienza, un cliente su due ci richiede l'attivazione di un sistema di Newsletter.

La domanda successiva, da bravi sviluppatori Open Source, è: 

“esiste qualcuno che l’ha già fatto?”

Nel nostro caso specifico ci chiediamo:

“ci sono dei prodotti Plone per la gestione delle newsletter?”

La risposta è ovviamente “Sì” e quindi nel corso degli anni abbiamo installato, testato, litigato, patchato, utilizzato tre diversi prodotti: Singing & Dancing, EasyNewsletter e ploneGazette.

A partire da questo articolo andremo ad analizzare i singoli prodotti, per scoprirne pregi e difetti e i miglioramenti che in qualche caso abbiamo apportato.

Singing & Dancing

nome prodotto: collective.dancing (+ collective.singing)
owner e maintainer: Daniel Nouri
pagina ufficiale: http://plone.org/products/dancing

I canali di diffusione sono lo strumento con cui viene definito comportamento e aspetto di una newsletter. Infatti per ogni singolo canale (se ne possono creare quanti se ne vuole, a seconda di quante diverse newsletter si vogliono avere all’interno del proprio portale) si possono definire svariate elementi, come la possibilità di iscriversi o meno, un eventuale testo da aggiungere in testata e nel footer della mail spedita e degli stili CSS da applicare.

Come abbiamo detto, non utilizzando nessun Archetype particolare, volendo si può spedire qualunque contenuto del sito come newsletter semplicemente scegliendo la voce “invia come newsletter” dal menu “azioni” dell’oggetto, e poi scegliendo il canale di diffusione attraverso cui si vuole spedire.

Il prodotto prevede inoltre una comoda portlet di iscrizione che permette di iscriversi direttamente ad un canale, oppure passare prima per il form di iscrizione dove potrebbe esserci del testo informativo (magari impostato nella configurazione del canale).

Nostre impressioni

Ci siamo ritrovati ad usare Singing & Dancing per diversi clienti; l’abbiamo trovato molto potente e spesso fa bene il suo dovere; ci sono, però, alcune cose che non ci sono piaciute. Di seguito è riportata una serie di pro e contro per analizzare meglio la situazione.

PRO

• E' costruito sfruttando l'architettura a componenti di Zope3 e la libreria z3c.form

• E' estremamente estensibile e upgradabile in base alle proprie
esigenze

• Consente una buona gestione dei canali attraverso il tool di gestione

• La gestione delle iscrizioni è resa sicura mediante un codice di conferma inviato agli utenti

• Permette di spedire qualunque contenuto

• Buon supporto della comunity

• Buon supporto agli utenti con manuali, chat e gruppo dedicato.

CONTRO

• Per customizzarlo bisogna avere una buona conoscenza di z3c.form e dell'architettura utilizzata

• Non prevede la gestione decentrata delle newsletter

• Prevede un meccanismo di invio schedulato che non sempre funziona correttamente

• Se per sbaglio si cancella un contenuto (o un canale) che è in coda per essere spedito come newsletter, la coda non si svuota a meno che non si ricrei l’oggetto/canale vecchio

• Il processo di accodamento ed effettivo invio delle newsletter è un po' troppo macchinoso (bisogna eseguire 3 passaggi in tutto)

• E’ vero che si può spedire tutto, ma non essendoci controlli, si rischia anche di spedire l’intero portale.

Estensioni

Come dicevamo in precedenza, il prodotto è nato per essere particolarmente "upgradabile", quindi su pypi ci sono diversi prodotti che estendono il funzionamento di base di S&D a seconda delle esigenze.
Alcuni di questi li abbiamo creati anche da noi, come per esempio:

collective.dancingnotlikely

[http://pypi.python.org/pypi/collective.dancingnotlikely]
Dato che il corpo della newsletter è la vista dell’oggetto vero e proprio, dentro S&D è presente un dizionario di “sezioni” della vista da non riportare. Alcuni clienti però ci hanno fatto notare che venivano riportate anche le informazioni sul creatore dell’oggetto e la sua history. Abbiamo quindi creato un semplice plugin che aggiunge questi elementi nella lista di quelli da non mostrare.

To be continued...

Già a settembre 2011 volevo scrivere qualcosa sull'aggiornamento dei requisiti della Legge Stanca, senza riuscirci. Sono stato mosso da vari eventi che vorrei condividere con voi. E' un peccato che alcuni dei link raccolti non siano permanenti sul sito in questione.

Nel testo del DM 8 luglio 2005, con gli aggiornamenti (ma datato 2010), e sul documento di presentazione delle linee guida dei siti web della PA, avevo letto che la consultazione che sarebbe seguita alla proposta di aggiornamento 2011 (avviata l'11 maggio) si era conclusa l'11 luglio, cercando di fare luce sulla situazione nel documento delle linee guida stesso avevo anche letto anche la nota 17. Eccola:

“Al momento dell’aggiornamento delle presenti Linee guida, l’Allegato A del Decreto Ministeriale 8 luglio 2005 è in via di revisione per permettere un adeguamento della normativa italiana alle evoluzioni degli strumenti tecnologici e delle regolamentazioni internazionali intervenute dalla sua pubblicazione. Attualmente, terminata la fase di consultazione pubblica, la proposta di adeguamento è stata notificata alla Commissione europea, ai sensi della Direttiva 98/34/CE, e potrà essere adottata al termine del periodo di statu quo previsto (settembre 2011). Si veda: Direttiva 98/34/CE".

Seguendo quest'ultimo link avevo trovato scritto che la fine del periodo di status quo era stato il 22 settembre 2011, cosa che suggeriva senza troppe ambiguità che questo fosse l'ultimo aggiornamento entrato in vigore.

Pensai immediatamente: e perché nessuno ne parla sul web? Forse mancava solamente una pubblica approvazione da parte del gruppo di lavoro e un aggiornamento delle date?

Allo stato attuale, diversi Enti Pubblici, tra cui alcune Regioni, considerano già la possibilità di fornire una doppia scelta: conformarsi ai vecchi requisiti Stanca (22) o ai nuovi (12), aggiornati dal DM e basati su un adeguamento alle WCAG 2.0.

In generale, cosa si può dire sulle novità? Alcune di queste sono sicuramente l'utilizzo di javascript “accessibile” e quindi javascript è inserito tra le tecnologie utilizzabili. Chiaramente però è necessario che sia implementato nel rispetto dei requisiti.

Senza entrare troppo nello specifico di tutti i requisiti riformulati, ne vorrei segnalare semplicemente uno sul quale occorre porre attenzione, fin dalla fase iniziale di progettazione:

Requisito 11 - Assistenza nell'inserimento di dati e informazioni

Questa è sicuramente una fase del progetto che va pianificata e su cui difficilmente sarà possibile intervenire a posteriori in maniera completa.
Al di là dei suggerimenti e dell'informare l'utente sulle sue interazioni, la revisione e la correzione delle informazioni inserite, anche a posteriori, implica l'esistenza di funzionalità che permettano queste operazioni.

In sostanza occorre comunque essere allineati con le WCAG2.0, le linee guida del W3C in materia, le quali il 3 gennaio 2012 sono state affiancate dagli aggiornamenti dei due principali strumenti di comprensione e di apprendimento delle tecniche per le WCAG2.0.

Sicuramente per districarsi in materia occorre ripartire anche da questi strumenti aggiornati che ci sono stati messi a disposizione.

All'estero si cerca di fare il punto della situazione. Lo si è fatto da poco a San Diego, con una bella e articolata conferenza sull'accessibilità, (#CSUN12), the CSUN 27th Annual International Technology and Persons with Disabilities Conference. 

Questo è un bell'articolo che parla di alcuni punti emersi alla conferenza,
del disagio, non solo italiano, nel cercare informazioni chiare anche per i principianti dell'argomento e quindi, della possibilità di fornire nuovi strumenti di consultazione semplificati (vedi anche questo) e dell'approccio "Be the fire fighter, not the cop" ovvero del focalizzare l'attenzione sul processo di aiutare a capire e a formare sull'argomento e non l'avere come fine il punire.

A Roma ci prova fra poco 10 maggio 2012 un manipolo di coraggiosi con un piccolo incontro di aggiornamento Innovazione tecnologica e responsabilità sociale:

Seguite l'evento su Facebook. (ci saranno aggiornamenti anche sulla location)

Sarebbe davvero bello se questo silenzio si sciogliesse e potessimo capire insieme quali sono le nuove prospettive. Quali le implementazioni possibili, le soluzioni pratiche, le opportunità per l'accessibilità che il web può offrire oggi. Come ho imparato fin dal primo giorno da un vecchio amico che fa formazione in questo settore, l'accessibilità è un processo e il processo va anche aggiornato. 

Bibliografia:

03-01-2012
WCAG Techniques Updated - Learn about the informative guidance

22-09-2011
Legge Stanca e accessibilità: cosa cambia?

15-06-2011 
Aggiornamento Legge Stanca

Documenti:

11-12-2008
Web Content Accessibility Guidelines (WCAG) 2.0
W3C Recommendation 11 December 2008

03-01-2012
Techniques for WCAG 2.0

03-01-2012
Understanding WCAG 2.0

Sitografia:

http://www.w3.org/WAI/

http://www.w3.org/WAI/Technical/Activity

http://radharc.com.au/2012/01/the-good-points-of-wcag2/

Link di cui si è persa la consistenza nel sito di origine:

http://www.innovazionepa.gov.it/TestoPDF.aspx?d=19451

http://www.innovazionepa.gov.it/lazione-del-ministro/linee-guida-siti-web-pa/presentazione.aspx

http://www.innovazionepa.gov.it/media/835828/linee_guida_siti_web_delle_pa_2011.pdf

Il crescente successo di Plone nella PA italiana è innegabile, i Clienti soddisfatti (tra cui i membri di PloneGov Italia) non mancano, ma i positivi risultati non sono ancora bastati a garantire la meritata notorietà al più modulare ed evoluto dei CMS liberi di classe Enterprise.

E, se per ora Plone non è ancora il nome più citato tra i CMS, immaginate cos'era cinque anni fa!

Risalta quindi ancor di più la lungimiranza con cui Arpa Veneto, nel Maggio 2007, lanciava un bando con base d'asta di 205.000 Euro per il rifacimento in Plone di tutta la galassia di siti Web gestiti dall'Ente. Si trattava del più grande bando Plone mai visto prima in Italia, e anche per RedTurtle fu una "prima" assoluta (prima commessa RedTurtle di questa dimensione, complessità realizzativa, articolazione burocratica), cui ebbi il piacere di contribuire portando un'esperienza da "vecchio volpone" nella redazione dell'offerta tecnica.

La soluzione RedTurtle per ARPAV

Abbiamo realizzato una soluzione globale comprensiva di Intranet, Portale Web, siti satellite, integrata con varie banche dati ambientali e meteo-climatiche, bollettini e informazioni utilizzando anche tecnologie GIS condivise con il Sistema Informativo Nazionale Ambientale (SINANET).

Integrato con applicazioni legacy e al centro di una rete di siti tematici, il portale Arpav è inserito in un'architettura informativa di grande complessità: alimentato da numerose origini dati grazie a un sofisticato sistema di "abilitatori" HTML e XML, il nuovo portale è completo dal punto di vista informativo e funzionale, è ricco di servizi online e aperto all'interazione con il pubblico.
In una delle Regioni italiane di maggior successo turistico, il portale è destinato ad attirare l'attenzione di un pubblico non solo regionale, ed è quindi stato configurato per gestire elevate moli di traffico, come quelle tipicamente associate alle richieste di servizi meteo, alla qualità dell'aria e ad altre informazioni di pubblico interesse.

"A long and winding road..." - un piccolo passo indietro

Mettendo in gioco le nostre migliori risorse realizzammo un'offerta, poi rivelatasi vincente, comprensiva della progettazione dell'architettura hardware e sistemistica a supporto del complesso dispiegamento, giocato su due piani (portale e Intranet) e comprensivo di una serie di siti a corredo.

Pronti a partire, nel Luglio 2007 ricevemmo la notizia della sospensione della gara per motivi di riorganizzazione interna: riaperta ad Agosto, la gara ci veniva aggiudicata nel Gennaio 2008. La redazione del progetto esecutivo coincideva con l'avvio di una fase di commissariamento dell'Ente, che si rifletteva, tra l'altro, in una radicale ridiscussione del progetto e delle sue priorità. Questa fase transitoria si è conclusa l'anno scorso, con la fine della gestione commissariale e con il collaudo formale a Luglio 2011. La messa in produzione è avvenuta il 18 gennaio di quest'anno.

"And the winner is..."

"Bene," si chiederanno i miei lettori, "cosa c'è di straordinario?".
Dal mio punto di vista, ci sono dei premi da assegnare:

• ARPAV va premiata per almeno due motivi: la scelta precoce di Plone, che ben si inserisce nelle scelte regionali per il free software, e l'aver mantenuto dritto il timone attraverso i pericolosi mari del commissariamento e della mancanza di fondi, non solo portando a compimento un progetto da alcuni dato per morto già sul nascere, ma, per strada, convertendolo in qualcosa di diverso e più adatto a ciò che l'Agenzia è diventata nel frattempo
• Plone va premiato per avere saputo rispondere a questo cambiamento: cosa che probabilmente nessuna tecnologia proprietaria avrebbe saputo garantire.

Noi di RedTurtle, che certamente abbiamo imparato a non dare nulla per scontato, e che abbiamo messo in gioco una resistenza da ultramaratoneti, il nostro premio lo abbiamo già avuto: un Cliente soddisfatto, tra i primi membri di PloneGov Italia, che ora potrà finalmente entrare in una fase di piena partecipazione (si parla già di un evento di confronto con la comunità PloneGov e non solo...).

Una soluzione completa ed integrata con costi d'esercizio contenuti per Comuni piccoli e medi dalle evolute esigenze comunicative...
Più facile a dirsi che a farsi. La risposta di RedTurtle si basa su Plone 4 e su un set di funzionalità standard che, nel caso del Comune di Sant'Agostino, un nostro nuovo Cliente con le idee molto chiare, sono state accompagnate da un layout grafico che unisce semplicità e gradevolezza.

Il sito soddisfa tutte le esigenze di base: adempiere agli obblighi di Legge, offrire un sito accessibile e completo, e al contempo promuovere il territorio con i suoi eventi. Il tutto, usando software libero, Plone e l'esperienza di RedTurtle nel servire le Pubbliche Amministrazioni Locali.

Ispirandosi a questo concetto di "completezza espandibile", RedTurtle ha recentemente confezionato due soluzioni Plone, dotate dei prodotti aggiuntivi di utilizzo più frequente, ed ha deciso di servirsi del MEPA di CONSIP per la loro distribuzione.

Il vantaggio MEPA

Il Mercato Elettronico della Pubblica Amministrazione da diversi anni consente alle PA un accesso rapido agli acquisti di beni e servizi: in questo caso, è CONSIP che si fa carico di accertare le caratteristiche di solidità e solvibilità delle aziende, e di incanalarne l'offerta in bandi "sempre aperti" verificando poi la rispondenza di quanto offerto ai requisiti di riferimento. L'Ente viene così sgravato dall'onere delle procedure di gara e di selezione fornitori, e deve semplicemente, per così dire, apporre la sua firma su di un contratto già pronto con prezzo "chiavi in mano", per la fornitura di uno specifico bene.

Come Plone aiuta... tutti!

Proprio la modularità di Plone, con i suoi prodotti aggiuntivi, ha consentito di modulare l'offerta su Plone base più un set preconfigurato di prodotti, ad attivazione opzionale. Dal lato RedTurtle, si è preconfezionata e semplificata una parte delle attività, potendo così proporre agli Enti, quale che sia la loro dimensione, un costo più che abbordabile, per dotarsi di una solida piattaforma, altamente estensibile, ed accedere al riuso di soluzioni in ambito PloneGov Italia.

RedTurtle non intende discostarsi dal suo storico profilo di realizzatore di soluzioni su misura, ma al tempo stesso intende giovarsi della completezza funzionale di Plone, già in versione base, per favorire l'ulteriore diffusione di questo apprezzatissimo software open.

Le due soluzioni CONSIP, simili a quella realizzata appositamente per il Comune di Sant'Agostino, sono cedute a costo differenziato a seconda della complessità e della provincia dell'Ente acquirente. Denominate "Portale Plone versione Base" (qui la descrizione per prima fascia e seconda fascia di Province) e "Portale Plone Versione Plus" (prima fascia e seconda fascia di Province).

Configura

Il sistema è molto semplice e molto
come-te-lo-aspetti:

1. vai su ploud.com
2. iscriviti: email, dominio, lingua
3. controlla la tua posta: c'è una mail di validazione con un link (devo davvero dirti che fare? :-)
4. ti chiederà la password che vorrai utilizzare
5. fatto.

Ci sono 2 tipi di servizi: gratuito e a canone mensile. Fondamentalmente si tratta della stessa soluzione, ma a pagamento ottieni:

• la possibilità di avere un tuo dominio
• più banda
• più spazio
• indicizzazione di google

Scegli il tema

Ora puoi impostarti il tuo tema tra quelli disponibili.

Tra gli 11 disponibili, io ho scelto "Earthling two" che avevamo adattato e rilasciato mesi fa su pypi.
E' bello vedere come ancora una volta la comunità funziona.

Tra l'altro l'uso di Diazo facilita molto l'implementazione di questo tipo di servizi: oggi ci sono "solo" 11 temi, ma è possibile aggiungerne altri.

Aggiungi funzionalità

Ora puoi aggiungere gli add-on, tra cui:

• Carousel
• Dropdown menu
• Autenticazione con OpenID
• PloneFormGen per creare moduli online
• Simple Social: vuoi farti mancare Facebook & co?
• Workflow personalizzati per cartella
• Copia di lavoro
• plone.app.caching: cache per siti più veloci

e i due nuovi cavalli di razza di Plone:

• Dexterity
• Diazo theme support

Quindi?

Beh, è Plone! Hai tutto quello che puoi fare con Plone, niente di meno. Ci sono alcuni add-on interessanti anche se c'è tutta una serie di ulteriori add-on che vorrei già poter usare.

L'attuale target di mercato è sicuramente molto basico e i temi sono veramente pochi (anche se con Diazo e un po' di olio di gomito puoi fare faville).

Seconde me ha le potenzialità necessarie per crescere. Stay tuned.

Prima di addentrarsi nella scelta di una delle soluzioni Plone per gestire sottositi, è bene iniziare il tutto con un'esame della propria organizzazione (o di quella del Cliente che vi ha richiesto "Plone e sottositi") per capire che cosa è un sottosito agli occhi dell'utilizzatore finale.

Può sembrare un passo inutile e dal risultato ovvio in quanto ogniuno di voi avrà in questo momento un'idea ben precisa ma posso assicurarvi che in questi anni abbiamo potuto vedere come questo concetto possa essere percepito in modo molto diverso.

Diamo innanzi tutto una definizione abbastanza generica da poter essere corretta in ogni caso (che dite, la scrivo anche su Wikipedia?).

Un sottosito è una porzione di un sito più grande ma che risente di un certo grado di indipendenza, pur mantenendo un legame col sito principale o con eventuali sottositi fratelli.

Fin qui tutto ok ma in seguito inizieranno ad emergere dettagli e molto spesso le similitudini tra le differenti richieste finiranno qui.

Le variabili in gioco sono le seguenti: indipendenza e legame col sito principale. Tutti vedono queste due caratteristiche in modo molto diverso.

Il nostro lavoro in questi casi è sempre stato analizzare innanzi tutto che cosa l'utente vuole ottenere.

Non ci siamo sorpresi quando alle volte il concetto di sottosito si è fermato alla richiesta di avere un dominio diverso col quale poter navigare una parte del il sito principale (e.g: sottosito.ente.it) oppure alla semplice applicazione di un tema differente. Non c'è nulla di male: un logo differente, o poco più, alle volte è tutto quello che i vostri utenti si aspettano e basta ai visitatori del sito per dare il giusto messaggio.

Gradi di indipendenza dal sito madre

Vediamo i vari scenari che si possono presentare.

Indipendenza 0%, legame col principale 100%

E' l'esempio fatto poco fa. Stiamo quindi parlando di siti dove l'indipendenza è nulla mentre il legale col sito principale è completo. L'utente ha solo bisogno di un richiamo visuale che identifichi l'entrata in un dipartimento diverso, una sottosezione dell'ente o della compagnia, etc.

Indipendenza 100%, legame col sito principale 0%

Altro non infrequente esempio è lo sviluppo di tanti piccoli sottositi, potenzialmente diversi tra loro in tutto.

Al termine dell'analisi di queste situazioni ci vede essere da parte vostra la lecita domanda "Ma perché dite che vi serve un sottosito? Quale è il legame col sito principale?".
Anche in questo caso non stupitevi se la risposta a volte è "Nessun legame!".

Molto spesso l'utente ha davvero bisogno di siti Plone completamente separati che condividono semplicemente:

• i prodotti installati
• una base dati utente comune (ma non è detto)
• l'uso di un dominio principale condiviso (ente.it/sottosito oppure sottosito.ente.it)

In questi casi Plone risolve da solo brillantemente la necessità, permettendovi di creare siti Plone separati nella stessa istanza Zope. Non vi serve altro!

La verità sta nel mezzo

Ovviamente nella maggior parte dei casi si ha "la sana via di mezzo".

In questa zona grigia molto spesso non vi serve chissà quale prodotto installato, ma qualche piccolo accorgimento.

Un esempio reale:

"i sottositi dovranno essere completamente indipendenti ma il link "Home" delle briciole di pane deve puntare al sito principale".

Quindi la Home del sottosito parte in realtà dalla seconda voce. Come otteniamo una cosa simile? Una semplice modifica che personalizzi la viewlet che genera questo elemento, per inserire un link assoluto al sito base. Per il resto: siamo ancora in presenza di un ambiente altamente indipendente. Il vostro "Plonista di fiducia" può farvi ottenere questo comportamento con poche ore di lavoro!

Da qui possiamo incontrare casi dove l'indipendenza cala piano piano e i prodotti da personalizzare ed installare crescono e si complicano...

Quando arrivate a questo, vale la pensa guardarvi attorno a capire che cosa vi serve davvero, e verificare che cosa Plone vi offre.

Altri prodotti che SI OCCUPANO DI sottositi

La necessità di ottenere sottositi è largamente sentita in Italia (forse anche legata alle recenti norme di razionalizzazione dei siti esistenti per gli Enti Pubblici) ma assai meno all'estero.

Al termine della Plone Conference di Budapest ho partecipato ad un Open Space dove si è parlato di sottositi, ma per il resto abbiamo dovuto faticare, inviare segnalazioni, discutere ed aspettare perché Plone ci facilitasse questo comportamento. Anche le discussioni a riguardo non sono poi tante (vale la pena leggere "Subsites in Plone: Review of info and call for sharing products, experiences, and best practices").
Ad oggi l'unico prodotto che sembra abbastanza mantenuto e aggiornato che si occupa di questa necessità è Lineage.

... almeno fino al rilascio del nostro prodotto!

Ad ogni modo con la release 4 il nostro CMS preferito è diventato un ottimo ambiente per avere sottositi.

Fare sottositi in Plone senza usare Plone: redturtle.subsite

La natura di redturtle.subsites si riassume in questo. Spostare al di fuori di Plone (Apache) tutta una serie di problematiche che, grazie a funzionalità native di Plone (anche se poco conosciute) è possibile gestire senza codice aggiuntivo.

Il prodotto nasce da alcuni esperimenti di RedTurtle ma viene portato poi avanti grazie alle esplicite richieste del Comune di Modena, che ha sentito da molti anni questa necessità in alcune installazioni ed è quindi un precursore dell'esplorazione dei sottositi in Plone.

Siamo in presenza di sottositi dove il rapporto "indipendenza/legame col principale" è variabile, ma comunque molto spostata verso un livello di bassa indipendenza ed altra integrazione: i sottositi fanno tutti parte della Rete Civica e questo non viene mai completamente nascosto.

Descriviamo nel dettaglio le richieste originali.

Back-end

I redattori dei sottositi devono poter accedere ad un indirizzo di back-end (anche detto "back-office") riservato, e si autenticano da quell'indirizzo (qualcosa come redazione.ente.it).

La caratteristica del back-end è quella di nascondere completamente tutto ciò che identifica i sottositi e mostrare il sito Plone principale. I sottositi risultano quindi semplici cartelle all'interno del portale visitato.

Anche il tema grafico può essere personalizzato fino ai limiti dello spartano, eliminando tutto quello che occupa spazio visivo nello schermo del redattore (o perché no, aggiungendovi elementi che abbiano il solo scopo di facilitare la redazione).
Il tema diventa quindi un vero e proprio tema riservato al back-end (ma non è obbligatorio).

Il redattore può quindi facilmente eseguire link interni (usando l'editor di Plone) tra documenti di sottositi diversi, creare collezioni che catturino informazioni da più sottositi, ...

Front-end

Questo comportamento deve cambiare nel front-end. Quando il visitatore accedere ad un sottosito deve ovviamente vedere il tema applicato a questo, ma deve avere un livello di integrazione col sito principale molto più basso.

I link alla home del sito, dal logo e dalle briciole di pane, devono riferirsi al sottosito corrente, non a quello principale.

Se non fosse per le ricerche effettuate nel sito o per la presenza di collezioni che qua e là possono mostrare contenuti proveniente dagli altri sottositi fratelli, potrebbe quasi sembrare di trovarsi all'interno si un sito Plone separato.

Con Plone è estremamente semplice (leggasi "senza installare nulla") isolare una cartella perché questa funzioni come un sito indipendente, ma questo influenzerebbe sia il back-end che il front-end (livello di indipendenza troppo elevato).

La nostra soluzione

Il nostro prodotto offre un modo estremamente semplice e poco invasivo di avere:

• un back-end che nasconda completamente i sottositi
• un front-end che mostri alcune cartelle come sottositi
• una metodologia semplice per creare temi aggiuntivi per questi sottositi

Creare uno di questi temi per i sottositi, o personalizzare un tema esistente, è estremamente semplice.

Il prodotto offre già alcune piccole personalizzazioni di Plone (modificandolo il meno possibile) per non dover sviluppare nessun codice aggiuntivo. Abbiamo anche fornito un tema di esempio per un sottosito Plone.

Le altre caratteristiche fornite sono:

• la navigazione di front-end interna al sottosito è altamente limitata al sottosito stesso (briciole di pane, link alla radice, ...)
• le ricerche sono eseguite a livello globale
• le collezioni comprendono tutto il sito (viene lasciato quindi al redattore il compito di limitarle, se lo desidera)
• ipotetici redattori di front-end (utenti esterni alla redazione) sono fortemente limitati, come se stessero lavorando in un sito Plone indipendente

Conclusioni

Il prodotto redturtle.subsite è semplicemente un aggregatore di tutta la splendida tecnologia sottostante e la pagina ufficiale del prodotto può essere vista come un manuale dei sottositi in Plone, per chiunque volesse intraprendere la strada (anche senza voler per forza usare redturtle.subsite potreste trovare informazioni interessanti).

La sua limitata dimensione dimostra come Plone sia di per se uno strumento estremamente maturo e, lasciatemelo dire, ancora una volta pieno di belle sorprese!