Oggi, invece che affrontare i soliti temi di migrazioni o contentrule, mi dedico ad un argomento più "grafico".

Pensando all’argomento di questo post, mi è venuto in mente che in azienda abbiamo una divisione dei ruoli con qualche connotazione sessista: i maschi sono rudi e badano al sodo quindi si occupano della programmazione backend, mentre alle donne, che hanno decisamente dei gusti migliori, spetta il compito di ricamare e colorare.

Detto questo, però, spesso i baldi giovani si vedono costretti a dare una mano alle dolci donzelle (anche se contro voglia), sia per alleggerire il loro carico di lavoro, che per supporto vero e proprio nella creazione di strumenti/strutture utili per poter creare il risultato grafico desiderato.

Una necessità ricorrente è quella di avere diverse sezioni principali del sito, ognuna contraddistinta da un colore che va a caratterizzare diversi elementi della pagina (per esempio i titoli, lo sfondo delle descrizioni o le testate delle portlet).

Ok, ma se i redattori vogliono gestire in autonomia i colori?

Il gioco diventa difficile quando le sezioni possono cambiare nel tempo, e le redazioni vogliono gestire i colori autonomamente.

Per risolvere questo problema, dopo diverse ricerche, ho trovato un valido esempio in un vecchio post di Kees Hink dove parlava esattamente di quello che mi serviva: applicare dinamicamente un determinato stile solo ad una sezione precisa del sito.

Innanzitutto serve una modifica agli Archetypes per poter aggiungere il campo di selezione del colore. Qui le possibilità sono diverse:

• si fa un nuovo Archetype folderish adibito al ruolo di cartella di tassonomia

• si usa archetypes.schemaextender e si aggiunge il campo a determinati AT folderish (le cartelle per esempio?)

• si crea una interfaccia “marker” per la quale si registra l’adapter di archetypes.schemaextender, e poi si applica questa interfaccia via ZMI (o con un qualche meccanismo di subtyping) direttamente alle cartelle desiderate.

L’ultima ipotesi è la più flessibile e di minor impatto, visto che si può decidere di marcare solo delle cartelle selezionate come tassonomie.

Una volta marcate le varie cartelle e impostato un colore (in valore esadecimale sarebbe meglio, così è già pronto da usare), non resta che creare gli stili veri e propri... ma come?

Seguendo l’idea del blog, basta registrare una viewlet dentro al viewletmanager IHTMLHeadLinks, che viene caricata negli header della pagina, e permette di definire nuovi stili e inserirli proprio nell'header, insieme agli altri CSS di Plone.

<browser:viewlet
 name="custom_color.viewlet"
 manager="plone.app.layout.viewlets.interfaces.IHtmlHeadLinks"
 class=".viewlets.CustomColorViewlets"
 layer="..interfaces.IMyProductLayer"
 permission="zope.Public"
 />

Questa viewlet andrà visualizzata ovviamente solo nei contenuti che sono all’interno di una tassonomia, e deve ritornare una stringa di codice CSS che darà proprio i colori impostati.

L'ultimo problema da affrontare è stato quello relativo al modo con cui generare questi stili.
In un primo momento avevo pensato di cablarli direttamente nel codice della viewlet, ma poi mi è venuto in mente che in un futuro avremmo potuto dover aggiornare quegli stili, quindi c'era bisogno di qualcosa di più dinamico e configurabile... e cosa c'è di meglio di un bel pannello di controllo che memorizza i dati nel registro di Plone?

Non mi dilungo su come creare un pannello di controllo basato su plone.app.registry perché è già stato trattato ampiamente dal nostro Luca Fabbri in non uno ma bensì in due post, poi si può trovare una buona guida scritta da Timo Stollenwerk o si può guardare il sorgente di diversi prodotti che ne creano uno, come ad esempio collective.analyticspanel.

Il campo nel pannello di controllo viene creato come una textarea, per poter inserire più righe di stili:

color_styles = schema.Text(
    title=_(u"Stili aggiuntivi"),
    description=_(u"Inserisci una serie di stili CSS aggiuntivi.
                    Dove vuoi usare il colore personalizzato,
                    scrivi la stringa $color$.")

Nella viewlet, ogni volta che viene disegnata, si va a prendere la tassonomia di appartenenza navigando a ritroso l'albero (se non sono dentro nessuna tassonomia ovviamente non viene disegnata) e si recupera il valore salvato nel registry per ritornarlo come CSS:

def render(self):
    taxonomy = self.getTaxonomy()
    if not taxonomy:
        return ""
    color = self.getFieldValue(taxonomy)
    if not color:
        return ""
    registry = queryUtility(IRegistry)
    settings = registry.forInterface(IMyRegistrySettings, check=False)
    css = settings.primary_color_styles
    if not css:
        return ""
    css = css.replace('\r\n', ' ')
    css = css.replace('$color, color) 
    return "<style type='text/css'>%s</style>" % css

def getTaxonomy(self):
    """
    Controlla ricorsivamente se l'elemento corrente è all'interno di una cartella
    marcata con la mia interfaccia definita precedentemente
    """
    for elem in self.context.aq_inner.aq_chain:
        if IMyMarkerInterface.providedBy(elem):
            return elem
    return None
def getFieldValue(self, taxonomy, field_name):
    """
    Ritorna il valore del campo definito con schemaextender
    """
    field = taxonomy.getField(field_name)
    if field:
        return field.get(taxonomy)
    return ""
 

In questo modo, si possono creare quante sezioni si vogliono, e dare ad ognuna un colore caratteristico diverso. Bisogna solo stare attenti a non usare troppi colori diversi in una pagina, per evitare di avere un "effetto arlecchino" non proprio gradevolissimo.

La foto in testata è di Sultry/sulky/silly, mentre l'immagine nel testo è di Joel Kramer

Lo ammetto, quando si avvicina il momento di scrivere un nuovo post del blog mi sembra sempre di non avere argomenti interessanti o di approfondire argomenti già raccontati (vedi i miei innumerevoli post sulle migrazioni, per esempio).

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!

Di cosa potrei parlare? Cosa ho fatto ultimamente di interessante da poter condividere?

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

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

Con l’uscita di versioni aggiornate di un software (Plone nel nostro caso), ci si ritrova spesso a dover aggiornare le vecchie installazioni per tenerle al passo con le ultime versioni rilasciate e godere delle migliorie apportate e delle nuove funzionalità.

Negli ultimi mesi, il mio lavoro è stato principalmente quello di “aggiornare” dei vecchi siti e migrarli da Plone 3 a Plone 4 (lo so, in ritardo di un paio d'anni).

Esistono sostanzialmente due modalità per migrare un sito Plone:

• esportazione dei soli contenuti dal vecchio sito (per esempio con strumenti come transmogrifier) e importazione di questi in un nuovo ambiente immacolato.
• migrazione del portale così com'è mediante il tool interno fornito da Plone stesso.

La migrazione con transmogrifier, di cui abbiamo già parlato precedentemente, in linea di massima è consigliata in quei casi in cui il vecchio portale potrebbe avere diverso “sporco” al suo interno, dovuto a svariati motivi (errori di gioventù dei programmatori, prodotti installati e mai utilizzati o mal rimossi, ecc.), oppure se si decide che parte dei contenuti attuali non servono più e si vuole portare dietro solo alcune sezioni.

Nel nostro caso avevamo degli ambienti abbastanza controllati, dove conoscevamo bene i prodotti installati (in parte sviluppati da noi e in parte trovati su pypi ma utilizzati da tempo) e il livello di sporcizia era minimo, ma soprattutto i portali dovevano essere migrati per intero.

Il tab "contenuti" di Plone, è una comoda vista delle cartelle (o contenuti "cartellosi") che permette di avere una visione generale degli elementi contenuti al suo interno.

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

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