Blog

Correzione degli url relativi con TinyMCE in Plone

Giorgio Borelli — Sat, 24 Mar 2012 16:35:00 +0100

TinyMCE è l'editor predefinito in Plone più o meno dalla versione e lo reputo un ottimo editor html. A volte però ha un comportamento che non mi piace molto, ad esempio, quando inserisco un link ad una risorsa che si trova sullo stesso dominio dove è pubblicato il sito, TinyMCE trasforma l'eventuale url assoluto del link - http://www.miodominio/nome_risorsa - in url relativo - nome_risorsa.

Questo comportamento non è di per se errato ma risulta fastidioso quando il link viene visualizzato in differenti contesti. Immaginiamo una portlet di testo inserita nella root del portale con all'interno un link ad una pagina chiamata pagina-di-test che si trova anch'essa nella root del portale.

Quando visualizzo la portlet dalla home page il link è corretto e punta direttamente a: http://www.miodominio.it/pagina-di-test

Cambiando contesto però, per esempio entrando nella cartella news il link all'interno della portlet punterà a: http://www.miodominio.it/news/pagina-di-test

Ora, per il meccanismo dell'acquisizione di Zope, il link punterà alla risorsa corretta e funzionerà correttamente ma esso non è formalmente corretto e potrebbe portare ad altri problemi legati soprattutto al SEO.

Un'impostazione all'interno del javascript di TinyMCE permette però di inibire questo comportamento dell'editor. Aggiungendo all'interno del file tiny_mce_init.js in portal_skin la seguente riga alla variabile init_dict non verranno infatti più convertiti gli indirizzi degli link inseriti.

convert_urls: false

Altre informazioni

Breve introduzione a plone.app.testing

Giorgio Borelli — Sat, 07 May 2011 18:59:32 +0200

Ho avuto l'occasione di provare il nuovo prodotto plone.app.testing e devo dire che sono rimasto positivamente impressionato. L'attenzione verso i test è sempre stata alta all'interno della comunità Plone ed anche questo strumento, che organizza e semplifica l'impostazione dei test, è all'altezza delle aspettative.

Cosa cambia con plone.app.testing?

La principale differenza, rispetto al precedente approccio ai test, è che plone.app.testing ci obbliga ad organizzare i nostri test secondo una serie di layer che si occupano di creare una serie di configurazioni ad hoc per i nostri test.

Ogni layer è quindi 'indipendente' dagli altri e deve contenere solamente le configurazioni necessarie per una specifica serie di test.

Sarà il sistema, durante l'esecuzione dei test, ad occuparsi dell'organizzazione e dell'ordinamento degli stessi in base ai layer. In questo modo i test appartenenti al medesimo layer vengono eseguiti insieme risparmiando tempo nella loro esecuzione.

All'interno di plone.app.testing sono già definiti alcuni layer preconfigurati che semplificano ulteriormente il lavoro: avremo quindi layer specifici per gli unittest, per i test di integrazione, fuzionali ecc.

Come districarsi nella foresta

Iniziamo dalla configurazione di una specifica sezione del buildout

...
[tests]
recipe = zc.recipe.testrunner
eggs = 
    egg.da.testare [test]
...

In questo modo, grazie a zc.recipe.testrunner, abbiamo definito una specifica sezione ed incluso il nostro pacchetto tra gli egg da testare.

Specificando l'opzione [test] indichiamo inoltre che per il nostro pacchetto dovranno essere prese in considerazione delle specifiche dipendenze definite all'interno del nostro prodotto nel seguente modo:

# setup.py
...
extras_require = {
    'test': [
        'plone.app.testing',
        ...
    ]
},
...

ora possiamo creare il nostro primo layer che sarà basato su PLONE_FIXITURE, un layer predefinito in plone.app.testing:

from plone.app.testing import PloneSandboxLayer
from plone.app.testing import PLONE_FIXTURE

class MyLayer(PloneSandboxLayer):
    defaultBases = (PLONE_FIXTURE, )

    def setUpZope(self, app, configurationContext):
        """Qui configuro l'istanza Zope importando, 
        per esempio, le direttive zcml del mio prodotto
        """
        import my.package
        self.loadZCML(package=my.package)

    def setUpPloneSite(self, portal):
        """Qui posso gestire alcune impostazioni di base di Plone.
        Per esempio installo il prodotto da testare
        """
        self.applyProfile(portal, 'my.package:default')

    def tearDownZope(self, app):
        """Qui posso inserire tutto quello che dev'essere
        eseguito alla fine del test
        """

a questo punto possiamo istanziare una serie di variabili per gestire test:

MYPACKAGE_FIXTURE = MyLayer()

from plone.app.testing import IntegrationTesting
MYPACKAGE_INTEGRATION_TESTING = IntegrationTesting(
                                  bases=(MYPACKAGE_FIXTURE, ),
                                  name="MyPackage:Integration")

from plone.app.testing import FunctionalTesting
MYPACKAGE_FUNCIONAL_TESTING = FunctionalTesting(
                                  bases=(MYPACKAGE_FIXTURE, ),
                                  name="MyPackage:Functional")

ed utilizzarle in un test:

import unittest

class MyIntegrationTestClass(unittest.TestCase):
    layer = MYPACKAGE_INTEGRATION_TESTING

    def test_dummy(self):
        """Un utile test!!"""
        self.assertEquals(2+2, 4)

Considerazioni

Penso che questo strumento sia eccezionale per la realizzazione dei test in Plone e consente di migliorare il processo di definizione degli stessi.

Occorre però abituarsi ad alcune piccole cose dovute al meccanismo dei layer. I layer di default si occupano infatti di configurare lo stretto necessario e quindi dobbiamo essere noi stessi a definire al loro interno tutto quello di cui abbiamo bisogno.

Ecco alcune cose da ricordare:

se abbiamo un prodotto Zope2 che utilizza il metodo initialize. Ovvero un classico prodotto per Archetypes dobbiamo ricordarci di installarlo manualmente all'interno del layer.
il plugin zc.autoinclude non funziona all'interno dei layer quindi dobbiamo ricordarci di includere tutti i file zcml necessari
portal adesso è impostato come chiave di self.layer in questo modo: self.layer['portal']
per eseguire operazioni con un ruolo Plone particolare possiamo usare: plone.app.testing.setRoles

Altre informazioni

Readme di plone.app.testing

Lo ammetto, con il buildout ci farei anche la pasta!

Giorgio Borelli — Sat, 07 May 2011 16:37:49 +0200

Quando si lavora ad un progetto software all'interno di un gruppo è imprescindibile che l'ambiente di lavoro sia condiviso. Condiviso non vuol dire necessariamente che tale ambiente risieda su una macchina comune bensì che l'ambiente debba condividere le medesime caratteristiche quali le versioni del software installato, configurazioni ecc. Altra caratteristica imprescindibile è che tale ambiente possa essere replicato su diverse macchine per facilitare le operazioni di sviluppo, staging e deploy.

Per fare tutto questo, in ambito python (ma nulla ci vieta di utilizzarlo in altri ambiti) abbiamo un utilissimo strumento: zc.buildout

Buildout è uno strumento che si compone di uno o più file di testo contenenti le configurazioni necessarie alla messa in opera del nostro ambiente lavoro. Ogni file di configurazione è suddiviso in più sezioni e ad ogni sezione è associata una specifica recipe che consente l'eseguzione di differenti istruzioni.

Grazie e queste ricette possiamo qundi compilare ed installare software, eseguire comandi ed ancora configurare differenti parti del nostro ambiente di lavoro secondo le specifiche del progetto. Possiamo inoltre differenziare l'ambiente di lavoro in base a differenti necessità.

Immaginiamo di dover installare una serie di egg ognuno ad una determinata versione, immaginiamo uno sviluppatore che debba utilizzare differenti versioni del medesimo software per differenti progetti o ancora differenti configurazioni del medesimo software; cosa gli conviene fare? sperare di trovare tutte le differenti versioni del software di cui ha bisogno disponibili per il suo sistema? compilare ogni volta tale software dai sorgenti? configurare manualmente tutto?

E se per 'malaugurata sorte' un altro sviluppatore subentra in uno di questi progetti? Anche quest'ultimo deve ripetere nuovamente le medesime operazioni del collega sperando di non incorrere in nuovi problemi?

Nando, fatti un favore, usa il buildout!

Con zc.buildout puoi installare quello che vuoi e configurarlo come vuoi, puoi condividere con il gruppo di lavoro solo pochi file di testo contenenti le configurazioni per replicare il medesimo ambiente di lavoro ed il giorno che tale ambiente non ti serve più devi solamente cancellare una directory.

E se il tuo sistemista preferisce compilare a mano una determinata libreria piuttosto che utilizzare la versione fornita con il sistema operativo per installarlo sul server del momento? una semplice configurazione in più ed anche il tuo sistemista, già oberato di lavoro, sarà ben fece di snellire il processo di deploy.

La morale? Io uso il buildout per tutto quello che posso, anche per compilare una determinata versione di python qualora essa non fosse più (o non fosse ancora) disponibile per un determinato sistema operativo.

Nessuno ormai si sognerebbe di installare Plone senza buildout (infatti lo stesso unified installer lo utilizza) ed a volte mi chiedo come fanno gli sviluppatori di altri progetti in ambito python senza questo strumento.

Spesso mi chiedo come soddisfano le esigenze descritte qui sopra gli sviluppatori di altri progetti quali Django, Openerp o ancora Turbogears. Configurano tutto manualmente a suon virtualenv ed easy_install? Trovano questa modalità appropriata? Facilmente condivisibile? E ancora mi chiedo come e quanto incide l'eventuale difficoltà d'installazione nel processo di sviluppo e rilascio di un software?

Altre informazioni

Plone testbrowser ed AmbiguityError

Giorgio Borelli — Mon, 28 Feb 2011 18:51:31 +0100

Quando stiamo scrivendo dei test per Plone utilizzando testbrowser (solitamente Products.Five.testbrowser.Browser) può capitare che all'interno di una pagina web coesistano due elementi con lo stesso nome.

Per esempio, dato questo sorgente html:

...
 <form ...>
  <input type="text" name="nome"/>
 ...
 </form>
...
 <form ...>
  <input type="text" name="nome"/>
 ...
</form>
...

e volendo eseguire un test che verifichi il funzionamento di una delle due form, potremmo incappare in AmbiguityError:

>>> from Products.Five.testbrowser import Browser
>>> browser = Browser()
>>> browser.open('url_della_pagina')
>>> browser.getControl(name='nome')
*** AmbiguityError: name 'nome'

tutto ciò è frustrante ma ha una soluzione; è sufficiente passare un parametro index al metodo getControl in modo da discernere uno dei due elementi trovati.

Quindi:

>>> browser.getControl(name='nome', index=0)
<Control name='nome' type='text'>

ci restituirà il primo elemento trovato mentre:

>>> browser.getControl(name='nome', index=1)
<Control name='nome' type='text'>

ci restituirà il secondo elemento.

Plone.it - lavori in corso

Giorgio Borelli — Sat, 30 Oct 2010 17:18:27 +0200

All'ultimo symposium di Sorrento ci siamo impegnati a rinnovare la sezione scopri del sito italiano di Plone.

In occasione della Plone conference di Bristol io e Maurizio Delmonte siamo finalmente riusciti a presentare il lavoro svolto negli ultimi mesi che si è basato su pochi concetti fondamentali:

incentrare la comunicazione sull'utente in prima persona. Cosa può fare per me Plone
creare un hub comunicativo facilmente manutenibile con poche risorse che porti l'utente a trovare informazioni aggiornate all'interno degli altri siti della comunità
dare risalto ai progetti internazionali legati a Plone, come Plonegov, PloneEdu ecc.

Ecco il risultato confrontato con l'originale (clicca sulle immagini per ingrandirle):

Cinque minuti di JQuery Tools e Plone 4

Giorgio Borelli — Thu, 09 Sep 2010 22:49:05 +0200

L'ultima versione di Plone sfrutta le possibilità offerte da JQuery Tools per creare dei notevoli miglioramenti della sua interfaccia utente.

Molte delle form usate più frequentemente, tra le tante la form dei contatti, ora vengono visualizzate all'interno di popup migliorandone l'aspetto a l'usabilità.

Il punto di partenza risiede nel pacchetto plone.app.jquerytools che include la libreria JQuery Tools fornendo alcuni utili javascript che ci permettono in pochi passi di creare questi overlay.

Un esempio pratico

Nel nuovo tema di default di Plone, Sunburst, cliccando sul link in alto a destra fatti riconoscere, vedremo apparire un popup contenente la form per il login al sito.

Analizzando il sorgente html non notiamo nulla di strano:

...
<dl id="portal-personaltools">
   <dt id="anon-personalbar">
     <a href="http://.../login_form">Fatti riconoscere</a>
   </dt>
</dl>
...

ma se andiamo a vedere tra i javascript troviamo un qualcosa di interessante (Products/CMFPlone/skins/plone_ecmascript/popupforms.js):

// login form
$('#portal-personaltools a[href$=/login],
 #portal-personaltools a[href$=/login_form],
 .discussion a[href$=/login_form]').prepOverlay({
    subtype: 'ajax',
    filter: common_content_filter,
    formselector: 'form#login_form',
    ...
 });

Questo breve javascript permette di intercettare il link della form di login e trasformarlo in un popup con la funzione prepOverlay.

Le parti importanti del javascript riguardano la configurazione di base dove possiamo definire:

subtype: il tipo di overlay a scelta tra image, iframe, ajax
filter: possiamo filtrare alcune parti di html che non ci interessano
formselector: l'elemento univoco che rappresenta la form da visualizzare all'interno del popup.

La definizione di prepOverlay la troviamo all'interno di un altro javascript, overlayhelpers.js (plone/app/jquerytools/browser/overlayhelpers.js):

La prima cosa importante da ricordare è che il parametro formselector deve identificare una form in
modo univoco in quando il corretto funzionamento dell'overlay deriva dalla presenza o meno della form all'interno del contenuto dell'html.

La seconda parte del javascript riguardante la login form prosegue nel seguente modo:

   ...
   formselector: 'form#login_form',
   noform: function () {
         if (location.href.search(/pwreset_finish$/) >= 0) {
            return 'redirect';
         } else {
            return 'reload';
         }
   },
   ...

Tale sezione indica a prepOverlay quali funzioni intraprendere dopo l'invio della form.

noform: viene preso in considerazione da quando, come dicevo prima quando la form viene inviata senza errori e discrimina le azioni da intraprendere.

Possiamo quindi definire alcune azioni dopo l'invio della form quali:

redirect: reindirizza l'utente ad uno specifico indirizzo
reload: ricarica la pagina
close: chiude semplicemente il popup

Consiglio a tutti di leggere la pagina riguardante plone.app.jquerytools su plone.org dove vengono specificati gli altri parametri che possono essere utilizzati, nonché di trarre spunto dal javascript popupforms.js che contiene tutti i javascript utilizzati per i popup delle form.

Uso Avanzato

Purtroppo non è mai tutto rose e fiori (soprattutto con il javascript). Immaginiamo che all'interno del mio popup devo richiamare, per una particolare esigenza un javascript che venga attivato su di un particolare elemento del popup.

Nel mio caso mi occorre un plugin per l'autocomplete di un campo di testo che fa una richiesta asincrona al server.

In una pagina normale avrei scritto qualcosa del genere:

$(document).ready(function(){
    $("#il-mio-input-text").Foo(
        ...
    );
});

Questo però non può funzionare all'interno del mio popup in quanto quando la pagina viene caricata il contenuto del popup, e quindi l'elemento con id il-mio-input-text, non esiste ancora.

Devo fare in modo che il metodo Foo venga chiamato al caricamento del popup.

Fortunatamente chi ha scritto overlayhelpers.js ha fatto un buon lavoro e quindi studiando un po'
capisco che posso passare un ulteriore parametro di configurazione a prepOverlay.

L'attributo config permette di passare tutte le configurazioni accettate dagli overlay di JQuery Tools.

Posso quindi sfruttare l'evento onLoad dell'overlay e modificare il javascript del popup nel modo seguente:

$('#link-per-attivare-il-popup').prepOverlay({
    ...
    config: {
         onLoad: function(){
              $("#il-mio-input-text").Foo(
              ... )}
    }
});

Needle in an enterprise haystack - Plone search engine integrations

Giorgio Borelli — Thu, 27 May 2010 17:56:57 +0200

A Sorrento Andrew Mleczko porta la discussione su un importante argomento ovvero l'integrazione di Plone con sistemi di ricerca ed indicizzazione esterni.

Il sistema di indicizzazione interno di Plone, il portal catalog, è un ottimo strumento che permette una rapida ed efficiente ricerca di contenuti all'interno di Plone. Tale strumento ha comunque alcune limitazioni che riguardano la diminuzione delle performance in sistemi di grosse dimensioni ovvero quando vengono indicizzate centinaia di migliaia di contenuti al suo interno.

Per ovviare a questo sono state proposte differenti soluzioni alternative al "catalog" che permettono di spostare all'esterno l'indicizzazione dei contenuti in modo da utilizzare sistemi dedicati esclusivamente alla ricerca.

A tal proposito vengono proposti due casi d'uso dove l'integrazione di un servizio esterno per la ricerca è stata la soluzione ideale per risolvere alcuni problemi.

Il primo caso interessante riuarda la realizzazione del progetto Biblioteca Accessibile dell'Università di Padova.

Il progetto, iniziato nel 2009, vuole condurre uno studio sui materiali in formato alternativo presenti nelle biblioteche italiane nonché realizzare un meta motore di ricerca che racchiuda le pubblicazioni di questo tipo presenti nelle biblioteche aderenti al progetto.

Le risorse bibliografiche possono essere raccolte in modo automatico interrogando i rispettivi cataloghi delle biblioteche piuttosto che essere creati direttamente in Plone dai bibliotecari stessi.

Un servizio automatizzato permette di raccogliere le informazioni dalle fonti precedentemente definite e popolare il catalogo esterno.

Per tale catalogo è stato usato solr, un software scritto in java open source. Tale software può essere utilizzato con Plone attraverso il pacchetto collective.solr che fornisce la struttura dell'integrazione.

Un altro progetto interessante riguarda l'indicizzazione di un insieme di siti Plone per la realizzazione del sistema di siti web dell'informagiovani dell'emilia romagna

Punto fondamentale del progetto, che, partendo dall'Emilia Romagna si estenderà a tutte le regioni italiane, è la realizzazione di un insieme di siti Plone che possano esssere consultati dall'utente finale come fossero un unico sito.

La soluzione del problema consiste nell'indicizzazione di ogni sito all'interno di un database centrale realizzato con Postgresql. Tale operazione viene eseguita con il pacchetto ore.contentmirror che prende il contenuto da Plone e lo rispecchia in un database relazionale. Per preservare la ricerca fulltext è stato aggiunto un plugin a postgresql che consenta tale funzionalita: tsearch2.

Sono questi due casi che rendono evidente come Plone si rivela un ottimo sistema che può essere integrato con altri per la realizzazione di soluzioni differenti che si adattano a differenti casi d'uso.

Grazie ad Andrew le slide dell'intervento sono già disponibili su slideshare.

collective.amberjack all'European Plone Symposium 2010

Giorgio Borelli — Thu, 27 May 2010 12:41:17 +0200

A Sorrento il primo talk della seconda giornata viene tenuto da Massimo Azzolini di Redturtle che presenta il prodotto collective.amberjack.

Questo interessante prodotto aggiuntivo contiene una serie di strumenti che permettono di creare dei tour guidati all'interno di Plone; tali tour possono essere utilizzati come supporto alla documentazione tradizionale e consentono agli utenti di toccare con mano le funzionalità di Plone.

Allo stesso modo un tour guidato può essere utilizzato all'interno del sito per spiegare agli utenti alcune procedure guidandoli nell'esecuzione dei singoli passaggi.

Il prodotto presentato si basa su un tool javascript che viene integrato in Plone attraverso una serie di pacchetti che forniscono un'infrastruttura che facilita la creazione di tuor personalizzati.

Ogni tour può essere creato attraverso la registrazione di una configurazione zcml e la definizione di una serie di dizionari che specificano alcuni parametri di base nonché descrivono i vari step dello stesso.

Un tour così definito può avere un numero differente di step che eseguono azioni sulle pagine html semplicemente discriminando gli elementi della pagina con una serie di regole definite con xpath o selettori css.

Doctor Jekyll and mister transform

Giorgio Borelli — Wed, 26 May 2010 17:34:17 +0200

Proseguono i talk all'European Plone Symposium 2010 e finalmente si parla di due interessanti prodotti:

collective.xdv - presentato da Laurence Rowe
collective.transmogrifier - presentato da Rok Garbas

Sono due prodotti che reputo assolutamente imprescindibili per molti aspetti del mio lavoro quotidiano.

Il primo prodotto permette di realizzare in maniera abbastanza semplice dei temi grafici per Plone dove l'aspetto puramente grafico è nettamente separato dal resto del sistema; possiamo in questo modo consentire a grafici specializzati non esperti in Plone di realizzare dei template in html statico e css e, successivamente, affidare ad un integratore il compito di creare una serie di configurazioni che permettono di prendere il contenuto da Plone ed inserirlo all'interno del template grafico.

Il funzionamento di collective.xdv è abbastanza semplice e ben documentato; la tecnologia utilizzata si lega ad altri progetti che implementano concetti molto simili in contesti non strettamente legati a Plone: Deliverance e xdv.

Riguardo questi due ultimi progetti troviamo documentazione e differenti esempi sul web.

A tal proposito posso citare un interessante post di Mikko Ohtamaa sull'integrazione di wordpress all'interno di Plone e le slide sull'uso di Deliverance in un caso d'uso molto interessante presentato l'anno scorso a Sorrento

Il secondo prodotto presentato, collective.transmogrifier consente di creare complesse configurazioni per la manipolazione di catene di dati. Il caso d'uso più comune è l'esportazione e l'importazione di contenuti per la migrazione di sistemi informativi.

Questo prodotto, di cui si sta parlando molto ultimamente, consiste in realtà in una serie di pacchetti che, utilizzati insieme, possono essere d'aiuto per la migrazione verso Plone 4 quando il normale processo di migrazione fallisce ovvero quando, per svariati motivi, non è possibile avere la medesima struttura di prodotti preesistente e quindi si rende necessaria un'aricolata manipolazione dei dati e dei contenuti esistenti.

Una parte interessante del talk riguarda la lezione imparata dallo stesso relatore quando, la presenza di un Data.fs di dimensioni importanti (>10Gb) e la necessità di dismettere codice creato ad hoc non più aggiornato ha reso necessario, per la migrazione dei contenuti da un vecchio Plone 2.x a Plone 4, l'utilizzo di collective.transmogrifier.

Rok Garbas ha identificato quindi i punti fondamentali da prendere in considerazione nella realizzazione di un sistema di migrazione:

fare in modo che la migrazione sia ripetibile (per esempio attraverso l'uso di Genericsetup)
la migrazione di differenti parti di una pagina possono essere fatti separatamente
è importante separare la migrazione in step separati import-export
il monitoraggio della migrazione è un passo fondamentale per il successo della stessa
il processo di creazione di un blueprint è talmente immediato è inutile complicarsi la vita creando codice totalmente riutilizzabile

Purtroppo, a differenza del prodotto precedente, nel caso di collective.transmogrifier la documentazione online è piuttosto scarsa. Consiglio a tutti coloro che intendono cimentarsi di leggere attentamente la documentazione presente all'interno dei vari pacchetti di transmogrifier ovvero i differenti doctest.

In italiano potete trovare due post:

Matt Hamilton - Event driven Programming

Giorgio Borelli — Wed, 26 May 2010 15:02:57 +0200

L'European Plone Symposium 2010 entra nel vivo, dopo il talk di Simone De Ponti sull'uso di Plone all'interno di un complesso sistema di pubblicazione aziendale dove Plone è stato integrato con differenti sistemi per realizzare uno specifico caso d'uso.

È tempo di Matt Hamilton, di Netsight, che ci presenta quale è il ruolo dei 'Plone integrators' e di come essi possono operare all'interno di Plone. A differenza degli sviluppatori essi usano Plone integrandolo con altri sistemi attraverso l'utilizzo di differenti prodotti aggiuntivi evitando di modificare parti sostanziali di codice.

Un problema fondamentale di questo lavoro riguarda la personalizzazione di prodotti già esistenti per lo sviluppo di nuove funzionalità senza dover per forza modificare il codice del prodotto stesso.

Il caso reale discusso nel talk presenta l'integrazione del prodotto plone.app.discussion con sistema esterno di anti-spam. Il prodotto in questione, che consente di gestire i commenti in Plone, comprende già al suo interno un sistema di captcha ma in questo caso si ha la necessità di aggiungere il supporto ad Akismet.

Per risolvere il problema è possibile seguire differenti strade:

Una prima soluzione possibile consiste nel rifacimento di alcune parti sostanziali del prodotto originale piuttosto che la sovrascrittura diretta di alcune parti di codice attraverso un sistema di sottoclassi. Ma questa soluzione potrebbe risultare piuttosto invasiva e dispendiosa in termini di tempo.

Un'altra via consiste nell'utilizzo della Zope Component Architecture per sovrascrivere solo alcuni componenti in modo da modificarne il comportamento standard.

La scelta finale però ricade sull'uso degli eventi; in questo modo è possibile aggiungere la funzionalità desiderata senza modificare in alcun modo il codice esistente. Ulteriori vantaggi consistono in una notevole facilità di implementazione del codice aggiuntivo all'interno di un piccolo prodotto.

Ma come funziona il tutto?

All'interno di plone.app.discussion sono presenti degli eventi che vengono attivati alla creazione di un commento. Dato questo presupposto possiamo quindi sviluppare una piccola porzione di codice che intercetta l'evento ed esegue una determinata azione.

La registrazione di un semplice subscriber in zcml permette quindi di realizzare la nostra funzionalità aggiuntiva.

<subscriber
    for = ".interfaces.IMyOBject
           .interfaces.IMyEvent"
    factory = ".event.myEventHandler" />

L'azione vera e propria verrà realizzata all'interno della classe myEventHandler.

Soluzioni di questo tipo possono essere realizzate in molteplici casi d'uso; a seconda dell'evento intercettato possiamo infatti configurare particolari comportamenti in base alle nostre esigenze.

Per es.

alla creazione di una cartella è possibile aggiungervi altri contenuti
alla creazione di un particolare tipo contenuto è possibile modificarne alcuni metatdata in base alle proprie esigenze
alla modifica di un contenuto possiamo verificare l'effettiva validità dei suoi parametri in base a determinate condizioni

Personalmente credo che la cosa più difficile in questo caso possa essere l'abitudine a lavorare in questo modo, dal punto di vista dello sviluppatore ci dev'essere la capacità di integrare un sistema coerente di eventi all'interno del proprio prodotto.

Da parte degli integratori ci vuole la capacità di conoscere gli eventi disponibili in modo tale da poterli intercettare per estendere le funzionalità dei prodotti utilizzati.

European Plone Symposium 2010

Giorgio Borelli — Wed, 26 May 2010 11:40:13 +0200

Nella splendida cornice di Sorrento è iniziato l'European Plone Symposium 2010. L'evento, organizzato da Abstract, è ormai un appuntamento annuale importante per tutti coloro che vogliono rimanere aggiornati sulle ultime novità riguardanti Plone.

Proprio in quest'ottica il symposium viene aperto da Geir Bækholt di Jarn con il talk Plone 4 and beyond che riassume il lavoro svolto negli ultimi mesi per la realizzazione di Plone 4.

Ad un anno di distanza dalla sua presentazione molte sono le funzionalità integrate nella nuova versione e tanto il lavoro che è stato fatto sino ad ora soprattuto dal punto di vista delle performance e dell'interfaccia utente. Il rilascio ufficiale è previsto per quest'estate e quindi viene sottolineata l'esigenza che gli sforzi di tutti si concentrino nel test delle funzionalità di Plone e dei prodotti aggiuntivi.

Se Plone 4.0 è pronto per gli ultimi test ed il rilascio, lo sguardo degli sviluppatori si è già spostato verso la release 4.1 dove verranno integrate alcune funzionalità non ancora pronte per la prima uscita quali:

plone.app.registry, un sistema per concentrare ed uniformare le configurazioni di Plone
plone.app.discussion, un nuovo sistema di gestione dei commenti che già è utilizzabiile come prodotto aggiuntivo su Plone 3
collective.amberjack, uno strumento promosso da redturtle per creare tour guidati in Plone

Le novità non finiscono qui in quanto altre saranno le migliorie che porteranno ad un rifacimento degli oggetti di tipo evento ed a una ristrutturazione degli oggetti collezione di cui verrà migliorato sia il backend di ricerca che l'interfaccia di gestione.

World Plone Day 2010 - Università di Macerata

Giorgio Borelli — Tue, 11 May 2010 10:12:05 +0200

Il 28 aprile 2010, in occasione del World Plone Day, è stata organizzata presso l'Università di Macerata una giornata di discussione su Plone facendo un particolare riferimento agli ambiti d'applicazione in campo accademico e universitario.

L'evento, organizzato dall'Università sotto la spinta di Maurizio Delmonte e di Abstract, è riuscito a richiamare più di cinquanta persone interessate alla discussione. Sicuramente un buon risultato considerato che è la prima volta che viene organizzato un evento su questo argomento a Macerata.

L'introduzione alla giornata del professor PG Rossi chiarisce subito le linee guida della discussione delineando quali siano le necessità intrinseche dei sistemi informativi web all'interno di un'università.

Da un punto di vista strutturale possiamo immaginare le università come delle aziende suddivise in differenti settori e dipartimenti dove ognuno di questi necessita di uno spazio ben definito con differenti peculiarità ed esigenze comunicative specifiche.

Il sistema di portali web dell'università è quindi un ecosistema complesso che ha assunto negli anni un'importanza sempre maggiore come fonte di informazione sia rivolta verso l'università stessa che verso l'esterno. Da qui nasce l'esigenza di dotarsi di un strumento flessibile che si adatti ai bisogni di ogni facoltà nonché si integri con differenti ed eterogenei sistemi informativi.

Proprio per queste caratteristiche a Macerata è stato scelto Plone per la realizzazione dei portali web dell'Università con la consapevolezza inoltre che sarà uno strumento adeguato alle esigenze dell'università negli anni a venire.

La scelta dello strumento tecnico è però solo il primo passo per l'organizzazione dell'informazione e l'erogazione dei servizi dell'ateneo. La continua formazione del personale coinvolto in questo processo è un momento fondamentale perché si definisca una consuetudine d'azione che evolve nel tempo per un progressivo miglioramento della comunicazione.

Sono questi i passi obbligati che trasformano un semplice sistema informativo in un vero e proprio strumento di lavoro consentendone l'evoluzione verso un sistema di knowledge management.

I miei sinceri complimenti a tutti gli organizzatori dell'evento per le ottime capacità organizzative nonché l'ospitalità e la cordialità dimostrata.

Vai la pagina dell'evento

Aggiungere una patch da buildout

Giorgio Borelli — Thu, 15 Apr 2010 10:31:14 +0200

Ho modifiato un prodotto di terzi e non ho accesso al repository dove risiede, non voglio quindi duplicare il prodotto su un mio repository e ho inviato agli autori la patch dei file modificati.

Coma fare ad utilizzare il prodotto modificato da me in attesa che vengano (o non vengano) accetta le modifiche da me apportate?

La ricetta collective.recipe.patch fa al caso mio; due righe in più al buildout e posso applicare la mia patch all'esecuzione del buildout.

[buildout]
parts = 
   patch-prodotto
...

[patch-prodotto]
recipe = collective.recipe.patch
egg = nome.pacchetto_python == 0.3.1
patches = nome_del_file.patch

Errore nella reimpostazione della pasword

Giorgio Borelli — Wed, 14 Apr 2010 11:25:21 +0200

Utilizzando collective.xdv mi sono accordo di uno spiacevole errore quando gli utenti volevano resettare la propria password.

Il sistema dava un errore generico nella reimpostazione della password. Questo errore però capitava solamente nel sito dove è stato applicato il tema grafico realizzato con collextive.xdv.

Una piccola ricerca mi porta a questa discussione e scopro che la soluzione è semplice:

ricordarsi sempre di inserire una regola per il tag <base ... />

Per esempio nel file delle regole inserire:

...
<replace content="/html/head/base" theme="/html/head/base"/>
...

e nel tema:

<html>
  <head>
    <base />
...

Creare un widget personalizzato con Archetypes

Giorgio Borelli — Thu, 18 Mar 2010 17:53:13 +0100

Mi occorreva un widget personalizzato per un mio content type quindi mi sono dovuto studiare il funzionamento del modulo Products.Archetypes.widget

Con piacevole sorpresa ho capito che la creazione di un widget personalizzato non è troppo complicato.

Buona parte delle funzionalità del mio widgets sono già presenti in StringWidget, uno dei widget più comuni.

Premesse

Quando ci si aproccia ai widget di Archetypes bisogna tenere presente alcune cose fondamenteali:

La prima è che ciascun widget può essere associato a uno o più Field di Archetypes.

La seconda è che ogni widget può avere principalmente due modalità: edit e view. La prima viene utilizzata per visualizzare il widget per l'inserimento e la modifica dei dati il secondo per la loro visualizzazione.

Per fare questo i procedimenti da seguire sono esattamente tre:

creare una classe widget che contenga le proprietà ed i metodi necessari al suo funzionamento
registrare il widget per uno o più tipi di campo
realizzare un template contenente una particolare macro per ogni modalità del widget

Realizzazione

All'interno del mio pacchetto creo un modulo widget.py che contiene la definizione del widget:

from Products.Archetypes.Widget import StringWidget
from Products.Archetypes.Registry import registerWidget

class MyStringWidget(StringWidget):
    """Un widget personalizzato basato su StringWidget"""

    # copio le proprietà del widget originario
    _properties = StringWidget._properties.copy()

    # qui posso aggiungere tutte le proprietà che voglio
    # esse potranno essere impostate alla definizione dello 
    # schema del mio archetype
    _properties.update({
        'macro' : "mystring_widget", # questo è il page template 
                                   # che verrà utilizzato dal widget
        'mia_proprieta' : 'una proprietà personalizzata'
    })

    def simpleValue(self):
        """Oltre a personalizzare ogni metodo originario 
           posso creare tutti i metodi che voglio"""
        return u"Troppo fico questo tutorial!!!"

# alla fine posso registrare il widget per un campo particolare
registerWidget(MyStringWidget,
               title='MyWidget',
               description=('Descrizione del mio widget'),
               used_for=('Products.Archetypes.Field.StringField'))

Adesso posso registrare il template -- mystring_widget.pt -- per il mio widget in uno skin layer copiando alla grande da string.pt ;-)

...
<!-- macro per la modalità view -->
<metal:view_macro define-macro="view"
  tal:define="kssClassesView context/@@kss_field_decorator_view;
              getKssClasses nocall:kssClassesView/getKssClassesInlineEditable;">

  <span metal:define-macro="string-field-view"
      tal:define="kss_class python:getKssClasses(fieldName,
               templateId='widgets/mystring_widget', macro='string-field-view');"
      tal:attributes="class kss_class;
                      id string:parent-fieldname-$fieldName">

     <!-- richiamando accessor() visualizzo 
          il valore del campo associato al widget -->       
     <span metal:define-slot="inside" 
           tal:replace="accessor">string</span>

     <!-- posso richiamare i metodi del mio widget nel seguente modo -->
     <span tal:replace="widget/simpleValue">valore del metodo simpleValue</span>

  </span>
</metal:view_macro>

<!-- macro per la modalità di edit
     l'ho lasciata uguale all'originale cfr. string.pt -->
<metal:define define-macro="edit">
  <metal:use use-macro="field_macro | here/widgets/field/macros/edit">
     <input metal:fill-slot="widget_body"
        ... 
     />
  </metal:use>
</metal:define>
...

Partendo da questa base posso quindi creare i widget che voglio a seconda del caso; consiglio di guardare cosa fanno i widget di default di Archetypes piuttosto che guardare il funzionamento di quelli nella sezione prodotti di plone.org.