Personal tools

February

Feb 29, 2012

Plone Konferenz 2012

Talks, the party and everything around PloneKonf in München

The Konferenz

From February 22nd to 24th the PloneKonferenz took place in München. There was a bunch of smart guys talking about their experiences with Plone. I really give thanks to the organizers for their invitation.

Since it was localized conference, the majority of the speakers were german so I had to interview some of them just after they finished their speech. I would suggest you two talks I really appreciate: Matt Hamilton and Bernhard Bühlmann's ones.

 

Focus your attention on his explanation about relationships and the best way to start them.

 

Here some other inspiring talks:

You may also want to take a look at Fulvio Casali's blog for a more detailed report.

We also proudly presented our use cases

Andrew Mleczko presented the new project management platform we are about to introduce in RedTurtle. Its name is Penelope since every web project never really ends. We integrated Plone, Trac and GoogleApps within a Pyramid application.

Project management software of your dreams:


 

I also had my two minutes of glory talking about how Plone can fit both town-wise sites to regional-wise portals and intranets.

Plone Konferenz 2012:


Photos photos photos

Enjoy some PloneKonf photos from us and some other participants:

Analisi della validazione dei campi Plone

Filed Under:

La validazione dei vari campi dei contenuti Plone è cosa nota e ben documentata, ma l'introduzione massiva dell'uso di archetypes.schemaextender ha cambiato l'approccio con cui affronto il problema

La validazione dei campi: oggi

Stiamo tutti aspettando il giorno in cui Plone darà l'estremo saluto al framework Archetypes, che dai tempi di Plone 2.1 ci fornisce non solo un ambiente di sviluppo per creare nuovi contenuti, ma anche i contenuti base con cui Plone viene distribuito.

Tutte le caratteristiche di Archetypes, compresa la validazione dei campi (field validation) sono ben chiare e documentate.

...
atapi.StringField('codice',
   validators=('isInt', 'isChissaCheCosa', ...),
   widget = atapi.StringWidget(
            label = "Il codice del prodotto",
            )
),
...

 

ErroreNella mia esperienza di sviluppo con questo framework, non ho mai apprezzato particolarmente il meccanismo di validazione... o meglio: l'ho apprezzato talmente tanto da usarlo così come viene fornito, usando tutta quella serie di validatori predefiniti che Plone fornisce, ma senza sentire mai un vero bisogno di crearne di nuovi.

I motivi sono due:

  • Plone ha già tutti i validatori che nel 90% dei casi bastano (capire se un campo è nel formato e-mail, se è un numero, ...)
  • Tipi di validazioni aggiuntive che possono essere richieste dalle specifiche di un progetto, sono risultate sempre un po' troppo specifiche, tanto da non giustificare lo sviluppo di nuovi validatori "general-purpose.

Sul secondo punto, meglio fare un esempio.

Ammettiamo di avere un campo "codice" (numerico) e per questo si abbia necessità di verificare che il campo abbia un certo valore:

  • Se la logica di validazione è semplice (e.g: "che il valore sia maggiore di 5", al 90% uno dei validatori base di Plone basterà (non sapete quante cose di possono fare usando ExpressionValidator e RangeValidator).
  • Se la logica è molto complessa (e.g: "il numero deve essere maggiore di 5, ma solo se è martedì, se c'è la luna piena ma non se l'utente corrente è nel gruppo dei revisori"), probabilmente non sarà riutilizzabile in un altro contesto.

Per di più: scrivere un nuovo validatore è semplice (anche se forse un po' noioso), ma validare uno specifico campo di un vostro tipo Archetypes è ancora più semplice.

Una delle funzionalità nascoste di Archetypes è che per validare un singolo campo è sempre possibile usare un "validation hook".

Ricordate? Il campo si chiamava "codice".

def validate_codice(self, value):
    ...
    if not ok:
        return "Validazione fallita"

 

Con questo semplice metodo aggiunto alla classe del contenuto, il campo viene validato in modo molto semplice e diretto.

  • Se il metodo ritorna qualcosa, quel qualcosa è il messaggio di errore (validazione fallita).
  • Se non ritorna nulla, la validazione ha avuto successo.

Un altro approccio (più pulito) è usare un adapter per IObjectPostValidation.

<subscriber provides="Products.Archetypes.interfaces.IObjectPostValidation"
            factory=".validators.MyPostValidation"
            />

 

Anche in questo caso: è più semplice questa strada che non sviluppare un validatore da usare una sola volta nella vita. Il bello dell'approccio qui sopra sta nel non dover modificare la classe del contenuto. Questo conta poco quando il codice è vostro, ma cosa ne dite della necessità di introdurre un processo di validazione per un campo di un tipo non sviluppato da voi (e.g: il tipo Evento base di Plone)?

Ma anche questo approccio è difficilmente riutilizzabile in più di un progetto; per di più è un metodo per validare l'intero contenuto al suo salvataggio, non un singolo campo.

Quando scrivere un validatore?

Una regola generale della programmazione: il riutilizzo del codice.

Se hai fatto lo stesso pezzo di codice in due diversi momenti, in diversi ambienti/prodotti e nel secondo caso hai ricopiato il codice dal primo, hai probabilmente sbagliato qualcosa la prima volta

Affermazione draconiana ma fondamentalmente vera... molto spesso durante la prima scrittura di un codice non si ha (e nemmeno si può avere) la lungimiranza da prevederne un utilizzo al di fuori del prodotto che si sta sviluppando.

Così si arriva alla seconda volta. Il codice è già fatto, ma non importabile nel nuovo progetto con semplicità, quindi si cede al Lato Oscuro del Copia/Incolla... Dopo la terza quarta volta probabilmente avrete capito che forse vale la pena sistemare le cose, e creare un modulo riutilizzabile!

Dopo la 18esima volta che mi sono ritrovato a scrivere una validazione per il CAP italiano e quando un secondo cliente mi ha chiesto di poter verificare la lunghezza minima di battute di un testo, ho messo tutto queste cose insieme in un prodotto: collective.itvalidators (ammetto che la scelta del nome fu quantomai infelice, quasi quanto Plone4Artists e Windows Millenium™).

Lo scopo di quel prodotto è raccogliere i nostri validatori più comuni per non doverli riscrivere da zero tutte le volte e per mantenerli in un unico punto. A dire la verità non avrei nemmeno raccolto tutti questi pezzi di codice in un insieme di validatori, se non fosse diventato così comune l'uso di schemaextender.

Validazioni Archetypes con schemaextender

Per tutti quelli che non lo conoscono, archetypes.schemaextender è un utilissimo prodotto Plone che ha cambiato completamente l'approccio di personalizzazione dei tipi Archetypes esistenti (siano essi i tipi base di Plone o altri prodotti di terze parti).

In pratica, vengono aggiunti nuovi campi a run-time allo schema (l'insieme dei campi che caratterizzano tipo) di un contenuto senza toccare il codice originale... wow! Uno dei limiti dell'approccio è che, per quanto si possa manipolare facilmente lo schema non si ha modo di manipolare anche la classe e il codice.

Quindi il semplice utilizzo dell'approccio "validation hook" mostrato sopra non può funzionare (al contrario, l'approccio tramite adapter per IObjectPostValidation continua a essere valido).

I validatori Archetypes, al contrario, sono definiti direttamente nello schema, quindi sono ancora utilizzabili usando schemaextender. Avere quindi la logica di validazione racchiusa in un modulo riutilizzabile in questo caso paga.

Feb 21, 2012

Un Mondo di Newsletter (parte 3)

PloneGazette

Un Mondo di Newsletter (parte 3)

Filed Under:

excursus sui prodotti per newsletter sviluppati per Plone

Ed eccoci arrivati al terzo ed ultimo, per ora!, articolo con tema Newsletter.
Se vi siete persi i primi due, catapultatevi a leggere Un Mondo di Newsletter (parte 1) e (parte 2).

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

PloneGazette

nome prodotto: PloneGazette
pagina principale: http://plone.org/products/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.

PloneGazette screenshot

 

 

 

read more

Feb 15, 2012

Un Mondo di Newsletter (parte 2)

EasyNewsletter

Un Mondo di Newsletter (parte 2)

Filed Under:

excursus sui prodotti per newsletter sviluppati per Plone

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 ufficialehttp://plone.org/products/easynewsletter

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

 

read more

Feb 08, 2012

Un Mondo di Newsletter (parte 1)

Singing & Dancing

Un Mondo di Newsletter (parte 1)

Filed Under:

excursus sui prodotti per newsletter sviluppati per Plone

“Quale portale web che si rispetti è sprovvisto di una newsletter?”

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

Singing and Dancing logo

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

read more