Every time a change is deployed on the release server, the best thing would be to "push" it automatically on production server, or as soon as possible (at least).

Maybe you can work with replicas of the template, but, in any case, the "optimum" would be:

So what?

Many solutions found over the Web, but...

As reported in this thread, automatic refresh design is something desired, perhaps to have something scheduled (agent), but even if low level Notes API are provided, it always requires an opened client and, in this case, a Windows client (API uses dll)!

Typically 'load convert' command is used for mail database

I remembered something about notes mail database administration, and a very cool stuff to upgrade mail templates, with this command:

load convert -n maildb.nsf * template.ntf

So, why not apply the same method to not-mail database?

I've investigated a lot, I've also opened a discussion on Stackoverflow and many authoritative people (Richard H. Schwartz, Per Henrik Lausten) answered me about different approaches, but I think that "load convert way" could be a good solution.

Be careful! If you try this, you can run into some problems: below I'll try to answer at the most commons I've experienced, and steps to resolve them.

Q:

What about if templates are on remote server?

A:

It's possible to directly refer the remote template, using this syntax:

load convert -n mydatabase.nsf * remoteserver!!template.ntf

where remoteserver is abbreviated name (e.g. removeServerName/OrgUnit/Org).

NOTICE: database and remote template could also be located in subfolder, so you can use:

load convert -n dir1/dir2/mydatabase.nsf * remoteserver!!dir3/dir4/template.ntf

Q:

When I send the command, I obtain this error: 'Mail Upgrade Failed: Unable to open design template file ......Unable to find path to server'"

A:

On production server, you need to create a connection to the release server, as shown in pictures:

Q:

After the connection is done, I obtain this error: 'The Address Book does not contain a cross certificate capable of validating the public key'

A:

A cross-certification between organizations is needed, in both directions (release server to production server and vice-versa), using server.id and cert.id.

Ready to go!

All the prerequisites for a correct communication are made.

Now is possible to schedule the refresh command whenever you want, in your preferred way, for example:

• making a program (see here)
• with a scheduled agent that send commands to server

Next lines show how to do this in a Java agent:

String command = "load convert -n mydatabase.nsf * remoteserver!!template.ntf";
System.out.println(session.sendConsoleCommand("", command));

That's all! Feel free to let me know what do you think about this approach. Any comment/review will be appreciated!

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

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

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

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

Installazione e uso

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

import pudb;pudb.set_trace()

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

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

Caratteristiche principali

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

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

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

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

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

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

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

Stack delle chiamate navigabile

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

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

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

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

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

L'API principale a cui si fa riferimento per aggiornare lo stato di un contenuto nel catalogo Plone è la chiamata a reindexObject:

>>> context.setTitle('Nuovo titolo')
>>> context.reindexObject()
>>> context.title()
'Nuovo titolo'

Fin qui, nulla di nuovo.

In alcuni casi è possibile limitare gli indici aggiornati a un sottoinsieme di quelli esistenti.

>>> context.setTitle('Nuovo titolo')
>>> context.reindexObject(idxs['Title', 'sortable_title', 'SearchableText'])
>>> context.title()
'Nuovo titolo'

In base all'attributo modificato, vale la pena aggiornare tutti gli indici che lo riguardano.

Quando la sicurezza incontra la ricerca

Un fatto meno noto: il catalogo di Plone è usato anche nella gestione della sicurezza.
In particolare esiste un indice dal nome allowedRolesAndUsers esplicitamente usato per una verifica di sicurezza: capire se un utente ha accesso a un contenuto (in pratica viene memorizzato nel catalogo se gli utenti hanno il permesso di "View" sul contenuto).

Perché tutto questo? L'alternativa sarebbe disastrosa in termini di prestazioni: caricare tutti i documenti risultanti dalla ricerca e verificare il controllo di sicurezza direttamente su questi.
Tale operazione può diventare molto lenta e dispendiosa, se pensiamo che una semplice ricerca testuale può portare a migliaia di risultati in un sito mediamente popolato.

E' quindi importante che questo indice sia sempre aggiornato. Per questo motivo, ogni volta che viene effettuata un'operazione che comporta un cambio di sicurezza di un contenuto (principalmente modifiche nella pagina di condivisione), l'indice viene aggiornato automaticamente.

Dato che una semplice chiamata al metodo reindexObject può essere relativamente dispendiosa (tenete sempre presente che Plone potrebbe indicizzare anche i file allegati e che l'operazione di re-indicizzazione di un file può essere piuttosto lenta), esiste un altro metodo che viene utilizzata al suo posto: reindexObjectSecurity.
Nel funzionamento base di Plone, questa chiamata si occupa di aggiornare solo l'indice allowedRolesAndUsers introdotto sopra.

Sicurezze alternative

Ma è vero che l'unico indice legato alla sicurezza sia allowedRolesAndUsers?
Nell'uso quotidiano di Plone sì, ma esistono alternative.

Vi porto due esempi.

collective.portlet.truereview

Sto parlando di un prodotto poco noto e di qualche anno fa: collective.portlet.truereview.

Questo prodotto applica lo stesso principio utilizzato col permesso "View" dall'indice allowedRolesAndUsers per un nuovo permesso legato all'attività di revisione dei contenuti: "Review portal content".
Per fare questo viene creato un nuovo indice: reviewerRolesAndUsers.

Lo scopo del prodotto è fornire una portlet di revisione alternativa per Plone che, a differenza di quella ufficiale, non richieda il caricamento del contenuto.
NB: il prodotto è fermo dal 2009, non sono certo che funzioni ancora ma lo trovo piuttosto didattico.

collective.localrolesdatatables

Il secondo esempio è legato al più recente collective.localrolesdatatables.

Questo prodotto vuole fornire una vista che permetta di ispezionare lo stato della sicurezza e delle condivisioni in un sito Plone.
Per fare questo è necessario capire su quali contenuti ci siano effettivamente delle personalizzazioni locali della sicurezza, ovviamente senza caricare i contenuti per non ricadere nel solito problema di prestazioni (ormai ci siamo capiti, vero?!).
L'approccio usato è quello di creare un nuovo indice "hasLocalRoles", un valore booleano che indica se un contenuto ha ruoli locali impostati o meno.

Espandere il funzionamento di reindexObjectSecurity

E' stato proprio utilizzando di recente collective.localrolesdatatables che mi sono imbattuto in un bug (di cui sono certo soffra anche collective.portlet.truereview):
il prodotto funziona a dovere, ma se la sicurezza di un contenuto viene aggiornata, l'indice "hasLocalRoles" non viene modificato a sua volta, almeno non fin quando l'intero documento verrà modificato (e quindi completamente reindicizzato).

Qual è il problema? Il metodo reindexObjectSecurity "non sa" che anche questo indice fa parte della sicurezza del sito.

Come risolvere?

Se andiamo ad analizzare l'implementazione di reindexObjectSecurity, troviamo questa riga di codice:

catalog.reindexObject(ob, idxs=self._cmf_security_indexes,
                      update_metadata=0, uid=brain_path)

Viene quindi chiesto di reindicizzare nel catalogo il documento (ob) e di limitarsi agli indici definiti nella tupla self._cmf_security_indexes (quindi non tutti gli indici).

_cmf_security_indexes è un attributo di classe definito per CatalogAware, nel pacchetto Products.CMFCore. La sua definizione è la seguente:

_cmf_security_indexes = ('allowedRolesAndUsers',)

La soluzione è molto semplice: estendere la lista di indici registrati in questo attributo (qui come ho modificato collective.localrolesdatatables):

from Products.CMFCore.CMFCatalogAware import CatalogAware

CatalogAware._cmf_security_indexes += ('mioNuovoSecurityIndex',)

Problemi?

Questo tipo di intervento ha un effetto collaterale: modifica l'attributo a livello di classe e si rispecchia quindi su tutti i siti Plone presenti nell'installazione. Potreste anche trovarvi nella situazione in cui il prodotto che necessita di questa modifica sia installato su un solo sito Plone, quindi il nuovo indice non sia presente in altri, eppure la modifica sia comunque applicata.

E' un problema? Per fortuna no!
Il catalogo Plone è molto tollerante: se viene chiesta la reindicizzazione di un indice non esistente, questo fallisce l'operazione senza sollevare eccezioni.

L'immagine di testata è di Alexandre Dulaunoy.

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

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

Rimanere ancorati al passato.

Tutto dipende dal bootstrap.py presente nel vostro buildout.

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

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

     python bootstrap.py -v 1.7.1
 

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

Il nuovo che avanza.

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

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

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

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

Working in the Lotus Domino environment, one way to achieve this goal could be a server-side component invoked by an XPagdies, to make the casting process: first, I need something in Java that could do the job for me, and after some search I came across XDocReport.

XDocReport means XML Document reporting

XDocReport provides Java API to merge XML document created with MS Office (docx, pptx) or OpenOffice (odt), LibreOffice (odt) with a Java model to generate report and convert it in another format (PDF, XHTML...).

Basicly, to make the template, main steps are:

1. create a template document with MS Word (docx) or OpenOffice (odt, ods)
2. compose the body of the document itself with variables to fill in
3. use Velocity or Freemarker syntax to set variables to replace.

In this case, I opted to use Velocity inside an ODF file.

Now let's start by explaining how to set up the whole project.

Installing server libraries

External libraries (.jar) that serve the purpose have been installed in the installation directory of the Domino server (jvm/lib/ext path).

These are the files:

commons-collections-3.2.1.jar
commons-lang-2.4.jar
fr.opensagres.xdocreport.converter-1.0.0.jar
fr.opensagres.xdocreport.converter.odt.odfdom-1.0.0.jar
fr.opensagres.xdocreport.core-1.0.0.jar
fr.opensagres.xdocreport.document-1.0.0.jar
fr.opensagres.xdocreport.document.odt-1.0.0.jar
fr.opensagres.xdocreport.itext.extension-1.0.0.jar
fr.opensagres.xdocreport.template-1.0.0.jar
fr.opensagres.xdocreport.template.velocity-1.0.0.jar
itext-2.1.7.jar
odfdom-java-0.8.7.jar
org.odftoolkit.odfdom.converter-0.9.0.jar
org.odftoolkit.odfdom.converter.core-1.0.0.jar
org.odftoolkit.odfdom.converter.pdf-1.0.0.jar
org.odftoolkit.odfdom.converter.xhtml-1.0.0.jar
oro-2.0.8.jar
velocity-1.7.jar

Dont' forget an important security setting in java.policy file:

Server-side tools

To manage the whole process I used an HTML page with a button that calls (via Ajax) an XPages, that deals with the fusion of the data (HTML string) in the template. At the end, I create the PDF file using iText libraries.

Related to XPages, it only call the servlet in the afterPageLoad event:

com.redturtle.XDocReport.mergeAndPDF(
	facesContext.getExternalContext().getRequest(), 
	facesContext.getExternalContext().getResponse()
);

This is how it looks the package, which includes the servlet:

Finally, this is the servlet code:

package com.redturtle;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.odftoolkit.odfdom.converter.pdf.PdfConverter;
import org.odftoolkit.odfdom.converter.pdf.PdfOptions;
import org.odftoolkit.odfdom.doc.OdfTextDocument;

import fr.opensagres.xdocreport.core.document.SyntaxKind;
import fr.opensagres.xdocreport.document.IXDocReport;
import fr.opensagres.xdocreport.document.registry.XDocReportRegistry;
import fr.opensagres.xdocreport.template.IContext;
import fr.opensagres.xdocreport.template.TemplateEngineKind;
import fr.opensagres.xdocreport.template.formatter.FieldsMetadata;

import lotus.domino.NotesException;
import lotus.domino.Session;

public class XDocReport {

	private static String VERSION = "XDocReport Version 1.0.0";
	static PrintWriter outClass = null;
	private static Session session = null;

	public static void mergeAndPDF (HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException, InterruptedException, NotesException {

                // NO DIIOP
		session=DominoAccess.getCurrentSession();
		try {			
			// 1) Load ODT file by filling Velocity template engine
			InputStream in = new FileInputStream("/tmp/template.odt");

			IXDocReport report = XDocReportRegistry.getRegistry().loadReport(in,TemplateEngineKind.Velocity);

			FieldsMetadata metadata = report.createFieldsMetadata();
			metadata.addFieldAsTextStyling("comments",SyntaxKind.Html,false);

			// 2) Create context Java model
			IContext context = report.createContext();
			context.put("comments", "<b>hello world</b>");
			
			// 3) Generate report by merging Java model with the ODT
			OutputStream out = new FileOutputStream(new File("/tmp/ODTProjectWithVelocity_Out.odt"));
			report.process(context, out);

			// 1) Load ODT into ODFDOM OdfTextDocument 
			in= new FileInputStream(new File("/tmp/ODTProjectWithVelocity_Out.odt"));
			OdfTextDocument document = OdfTextDocument.loadDocument(in);

			// 2) Prepare Pdf options
			PdfOptions options = PdfOptions.create();
			
			// 3) Convert OdfTextDocument to PDF via IText
			out = new FileOutputStream(new  File("/tmp/ODTProjectWithVelocityList_Out.pdf"));
			PdfConverter.getInstance().convert(document, out, options);
 
                        // Only manage response to Ajax call
		        response.setContentType("text/plain");
		        response.setCharacterEncoding("UTF-8");
			outClass = new PrintWriter(response.getWriter());
			printAgent("OK");
			return;
		} catch (IOException e) {
			e.printStackTrace();
		} catch (Exception e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}

	protected static void printAgent(String string) {
		outClass.println(string);
	}
}

Pay attention to these points:

1. comments - variable name inside ODF template
2. metadata.addFieldAsTextStyling("comments",SyntaxKind.Html,false); - fill variable with something in HTML syntax
3. <b>hello world</b> - HTML string to merge

NOTE: DominoAccess and JSFUtil are two very helpful classes written by Karsten Lehmann: see the full code. Thanks to them, DIIOP process for communication is not required.

Pro & Cons.

I think that it's a very powerful approach; the only limitation I've found is the restricted set of styles supported by the merge process (see there for details). Feel free to make some test using this approach, and let me know what you think :-)

Il caso

Come fa Plone a gestire
i gruppi virtuali??

Partiamo da un caso concreto, al quale sto lavorando in questi giorni. Ci sono degli user che, tramite un sistema di autenticazione federato, si collegano al sito. Quando questi si collegano per la prima volta, viene creato un utente vero e proprio nel sito Plone a cui viene impostata una proprietà (supponiamo sia "caratteristica_x=True"). Devo fare in modo di raggrupparli automaticamente.

In Plone tutto questo si fa con PAS e i suoi plugin in PlonePAS (si può vedere della documentazione qui). E proprio in quest'ultimo troviamo il codice che ci mostra come creare e gestire il gruppo degli "Authenticated User"; codice che si trova nei seguenti file:

• plugins/autogroup.py
• __init__.py
• Extensions/Install.py

Negli ultimi due moduli c'è il codice per registrare il plugin e installarlo. Si tratta di operazioni banali, e ci tornerò sopra più avanti quando mostrerò come creare un nuovo plugin. Nel primo modulo, invece, c'è tutta la logica che riguarda il funzionamento del plugin, ed è questo che mi interessa analizzare.

Analisi del plugin

Il plugin è generato tramite la classe AutoGroup. I meccanismi di PAS si basano sull'implementazione di interfacce tramite cui la classe si impegna a fornire un set di metodi; nella classe in analisi troviamo:

Tramite l'implementazione di interfacce, un plugin fornisce dei metodi e "promette" dei comportamenti

• IGroupEnumerationPlugin: fornisce metodi per l'enumerazione e la ricerca di gruppi
• IGroupsPlugin: fornisce un metodo tramite il quale, dato un principal (utente o gruppo) si ritornano tutti i gruppi a cui questo principal appartiene
• IGroupIntrospection: fornisce metodi per ottenere da un plugin gruppi e utenti dei gruppi
• IPropertiesPlugin: fornisce un metodo per ottenere le proprietà (titolo e descrizione) di un gruppo.

Per il nostro use case, è tutto corretto e l'unico comportamento che ci interessa modificare è quella fornito da IGroupsPlugin, tramite cui decidiamo se uno user è nel gruppo oppure no.

Creiamo un nuovo plugin

Per farlo, percorriamo i passi già citati sopra:

• si crea un plugin
• si registra
• lo si installa nel sistema.

Come detto, modifichiamo una sola funzionalita, data dal metodo getGroupsForPrincipal:

from App.class_init import InitializeClass
from Products.PlonePAS.plugins.autogroup import AutoGroup
from Products.PageTemplates.PageTemplateFile import PageTemplateFile

manage_addCustomGroupForm = PageTemplateFile("./zmi/CustomUsersGroupForm",
                                           globals())


def manage_addCustomGroup(self,
                          id,
                          title='',
                          group='',
                          description='',
                          RESPONSE=None):
    """Add an Auto Group plugin."""

    plugin = CustomUsersGroup(id, title, group, description)
    self._setObject(id, plugin)

    red_to = "%s/manage_workspace?manage_tabs_message=Custom+Users+Group+plugin+added"
    if RESPONSE is not None:
        return RESPONSE.redirect(red_to % self.absolute_url())


class CustomUsersGroup(AutoGroup):
    meta_type = "Custom users group"

    # IGroupsPlugin implementation.
    def getGroupsForPrincipal(self, principal, request=None):
        if principal.getProperty('caratteristica_x'):
            return (self.group,)
        return ()

InitializeClass(CustomUsersGroup)
 

Gli altri metodi nel codice sopra, manage_addCustomGroup e manage_addCustomGroupForm, sono utilizzati per l'aggiunta e la gestione del plugin in ZMI dentro la acl_users del sito: dobbiamo infatti creare un'istanza del plugin per avere il nuovo gruppo a disposizione.

Una volta scritto il codice del plugin lo dobbiamo registrare nell'inizializzazione del pacchetto:

from Products.PluggableAuthService import registerMultiPlugin

try:
    registerMultiPlugin(CustomUsersGroup.meta_type)
except RuntimeError:
    # Don't explode upon re-registering the plugin:
    pass

def initialize(context):
    context.registerClass(CustomUsersGroup,
                           permission=add_user_folders,
                           constructors=(manage_addCustomGroupForm,
                                         manage_addCustomGroup),
                           visibility=None
                           )

Fatto questo, possiamo considerare l'attività di sviluppo terminata. Se vogliamo istanziare il plugin con l'installazione del pacchetto, dobbiamo creare un import step dentro il quale fare qualcosa di questo tipo:

 
    ....
    portal = context.getSite()
    acl_users = getToolByName(portal, 'acl_users')
    plugins = acl_users.plugins
    if not 'custom_users_group' in acl_users.objectIds():
        manage_addCustomGroup(acl_users,
                            "custom_users_group",
                            "Custom users (Virtual Group)",
                            "CustomUsersGroup",
                            "Automatic Custom Group Provider")
        for interface in [IGroupsPlugin,
                          IPropertiesPlugin,
                          IGroupEnumerationPlugin,
                          IGroupIntrospection]:
            plugins.activatePlugin(interface, "custom_users_group"
    ....

In questo modo si aggiunge il plugin alla acl_users del sito e si attivano le interfacce per le funzionalità che il plugin dovrà gestire.

Conclusioni

Finito! Come possiamo vedere a questo punto nella gestione gruppi del sito, abbiamo un gruppo in più, che si comporta esattamente come il gruppo "Authenticated Users", tranne che per la condizione di appartenenza al gruppo; tale gruppo è disponibile anche nello sharing.

Per testarne il funzionamento, possiamo accedere al sito con un utente e verificare che non abbia permessi di nessun tipo. Dalla gestione gruppi possiamo assegnare il ruolo di Manager al gruppo appena creato e tornare a verificare con l'utente di cui sopra, che ora ha permessi da Manager nel portale.

L'immagine in testata è di evildan2

The story

Not all the content types are designed from the beginning with a container behaviour, a feature that can become a requirement in consequence of specification changes.

It happened also to me and in my case I had to deal with dexterity based content types. I started googling around and found this unresolved question on the dexterity mailing list.

Starting from the suggestions in the thread, I managed to find out a nifty solution that reveals some interesting aspects of the software we work with.

Creating the dexterity type

First of all let's create through the web the Example content dexterity type:

Then let's create the "Example 1" object:

Screwing it all up

Going to the portal_type edit form we can make "Example content" become a folderish object by modifying it's content type class, just replace "Item" with "Container".

To make something interesting it is  probably advisable to play with the "Filter content types?" and "Allowed content types" properties, allowing the creation of objects inside this container.

Once this is done the newly created objects show a folderish behaviour and view:

But the old one is completely unchanged and has to be migrated!

The objects have clearly a different nature, because they are instances of different classes. Going into a pdb we can clearly see it:

(pdb) portal['example-1'].portal_type
'example_content'
(pdb) portal['example-2'].portal_type
'example_content'
(pdb) portal['example-1']
<Item at /Plone/example-1>
(pdb) portal['example-2']
<Container at /Plone/example-2>

The portal type is the same but:

1. "Example 1" is an instance of plone.dexterity.content.Item
2. "Example 2" is an instance of plone.dexterity.content.Container.

Building the box

It is time to fold the paper sheet in to a box!

Aspeli's suggestion of replacing the __class__ attribute is a good starting point, but I found out that restarting the instance swallowed my changes.

I believe the answer can be found between the lines of this post from Dieter:

The main problem [about __class__ switching] is that the class is usually coded (for efficiency reasons) in the persistent references to an object. As soon as the container is loaded from the ZODB, a ghost is created for its persistent reference using the class mentioned there.

This means: it is not safe to change the class of a persistent object unless you although modify all its containers (otherwise, some persistent references remain with the old class. This potentially leads to non-deterministic behaviour).

A workaround that seems working to me is to detach the object from the ZODB, switch the class and put the object back in place, like shown in here:

(pdb) obj = portal['example-1']
(pdb) del portal['example-1']
(pdb) obj
<Item at /Plone/example-1>
(pdb) from plone.dexterity.content import Container
(pdb) obj.__class__ = Container
(pdb) portal['example-1'] = obj

This is unorthodox for sure, but for the time being it proved to be a working solution without side effects.

Let's finish the job

Ok, now the object is a Container instance!

(pdb) obj
<Container at /Plone/example-1>

But this is instance is not yet ready. As David Glick suggests:

I doubt that [switching with the __class__] will be sufficient, since containers have internal data structures that would need to get set up in order for the object to function as a container.

Infact visiting "Example 1" returns an error:

2013-02-20 16:03:23 ERROR Zope.SiteErrorLog 1361372603.770.0118314104451 http://localhost:8080/Plone/example-1
Traceback (innermost last):
 Module ZPublisher.Publish, line 115, in publish
 Module ZPublisher.BaseRequest, line 437, in traverse
 Module Products.CMFCore.DynamicType, line 147, in __before_publishing_traverse__
 Module Products.CMFDynamicViewFTI.fti, line 215, in queryMethodID
 Module Products.CMFDynamicViewFTI.fti, line 182, in defaultView
 Module Products.CMFPlone.PloneTool, line 847, in browserDefault
 Module Products.CMFPlone.PloneTool, line 715, in getDefaultPage
 Module Products.CMFPlone.utils, line 90, in getDefaultPage
 Module plone.app.layout.navigation.defaultpage, line 32, in getDefaultPage
 Module plone.app.layout.navigation.defaultpage, line 75, in getDefaultPage
 Module plone.folder.ordered, line 202, in __contains__
TypeError: argument of type 'NoneType' is not iterable

Checking the code, it turns out that the _tree attribute of the instance is None as it can be verified with some analysis on the object:

(pdb) obj._tree is None
True

This is because we miss some initialization, so it's time to dive into Python and check which parent class __init__ function we have to call.

To understand this I analyzed the method resolution order of the two classes and tried to filtered out the parent classes that were not interesting for my sake, either because their __init__ is identical to object.__init__ or because they are in common with the Item class, and so their init method were already called during "Example 1" initialization.

A first attempt returns this:

(pdb) container_mro = Container.__mro__
(pdb) item_mro = Item.__mro__
(pdb) container_only_klasses = [klass for klass in container_mro if not klass in item_mro and not klass.__init__ is object.__init__]
(pdb) pp container_only_klasses
[<class 'plone.dexterity.content.Container'>,
 <class 'plone.folder.ordered.CMFOrderedBTreeFolderBase'>,
 <class 'plone.folder.ordered.OrderedBTreeFolderBase'>,
 <class 'Products.BTreeFolder2.BTreeFolder2.BTreeFolder2Base'>,
 <class 'Products.CMFCore.PortalFolder.PortalFolderBase'>,
 <class 'OFS.Folder.Folder'>]

This considerably lowers the __init__ that we want to check. But we can go further, by noting that at the end it is enough to call the CMFOrderedBTreeFolderBase __init__method:

(pdb) from plone.folder.ordered import CMFOrderedBTreeFolderBase
(pdb) [klass for klass in container_only_klasses if not klass in CMFOrderedBTreeFolderBase.__mro__]
[<class 'plone.dexterity.content.Container'>]

Asking help on this class __init__ reveals:

(pdb) !help(CMFOrderedBTreeFolderBase.__init__)
Help on method __init__ in module plone.folder.ordered:

__init__(self, id, title='') unbound plone.folder.ordered.CMFOrderedBTreeFolderBase method

So to properly set up the missing blocks we just want to call this class __init__ passing as arguments the object itself, its id and its title:

(pdb) CMFOrderedBTreeFolderBase.__init__(obj, obj.getId(), obj.title)

Great, a new tree has born!

(pdb) obj._tree._tree
<BTrees.OOBTree.OOBTree object at 0xb4a85f5c>

To finalize our work the object has to be reindexed and the transaction committed:

(pdb) obj.reindexObject()
(pdb) from transaction import commit
(pdb) commit()

Final remarks

Of course code like this is intended for an upgrade step!

The techniques described in this post are for sure interesting and powerful, but I would not rely on such low level tricks for routine operations, i.e. they are useful for doing migration or management scripts but definitely not suited for a browser view!

My use case was slightly different and more complicated: I was working with classes derived from the dexterity Item and Content classes, but I simplified it for making an already complex topic clearer.

If you have a more complicated case, further actions may be needed to complete properly this migration. In my case, for example, I also had to change the portal_type and remap some attributes.

Many times I read about the suggestion of creating content types that are folderish even if not requested by the specification. As you can see this choice allows more flexibility and can save you from the need of writing migration scripts or upgrade steps at a later time.

Credits

Original image adapted by @petraplatz

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.

Per questo motivo abbiamo deciso di utilizzare il tool di migrazione nativo di Plone.
L’utilizzo del tool è molto semplice, basta un click e fa tutto da solo, però il difficile è stato “preparare” i vari portali alla migrazione.
Il nostro problema era che dovevamo migrare una ventina di portali in sequenza e il rischio era di rimanere impantanati nelle varie procedure.
Dopo diverse prove e migrazioni fallite, abbiamo trovato una serie di linee guida che ci hanno aiutato a sopravvivere e che sono tornate utili anche in successive migrazioni.

Analisi della situazione

Come prima cosa, bisogna fare un’analisi approfondita dell’utilizzo del portale, dei prodotti installati e dei contenuti creati.
In questo modo si può avere una panoramica su quanti e quali contenuti sono stati effettivamente creati, quali prodotti sono veramente utilizzati e bisogna portarsi dietro, e quali sono inutilizzati e si possono rimuovere per ottimizzare ulteriormente il portale.

Compatibilità dei prodotti su Plone 4

Dopo l’analisi preliminare, è utile testare il corretto funzionamento dei prodotti da mantenere, su un buildout Plone 4.
Per quelli di terze parti scaricati da pypi, di solito non c’è bisogno di fare molto: basta una veloce ricerca su pypi o su plone.org e il gioco è fatto. Se poi non sono compatibili, vuol dire che o sono stati superati da altri prodotti più evoluti (e forse è meglio informarsi meglio sull'eventualità di sostituirli), oppure possiamo sempre aggiornarli noi, in modo da dare un utile contributo alla comunità.
I prodotti sviluppati appositamente per i clienti, invece, vanno per forza sistemati. In generale, se non si deve fare un refactoring pesante ma solo un aggiornamento, un buon inizio è quello di controllare se presi e messi su un Plone 4 girano correttamente, ed eventualmente correggere a mano a mano gli errori che si riscontrano.
Molto probabilmente diversi template o importazioni si romperanno, perché alcune cose in Plone 4 sono cambiate; nessun problema, visto che sul sito di plone.org c'è una guida dedicata: http://plone.org/documentation/manual/upgrade-guide - in alternativa, Google o le varie mailing-list tornano sempre utili.

Rimozione dei prodotti inutilizzati

Il passo successivo consiste nella rimozione dei prodotti vecchi e/o inutilizzati.
E’ un passo importante, poiché non è consigliato portarsi dietro dei prodotti che non vengono utilizzati, o che già sappiamo non essere compatibili su Plone 4. Per questo vanno rimossi prima di effettuare una migrazione.

Promemoria: fare sempre i profili di disinstallazione!

Se un prodotto non è dotato di un profilo di disinstallazione fatto correttamente (e per esperienza posso dire che purtroppo molti sono così), potrebbe lasciare dei “residui” indesiderati nel nostro Data.fs.
Questi possono generare dei semplici warning  nel nuovo sito, come per esempio dei CSS o Javascript registrati e non più disponibili, ma nella maggior parte dei casi il problema riguarda adapter o persistent utilities che non vengono rimossi correttamente e rischiano di vanificare la migrazione.
Come per l’aggiornamento dei prodotti, se questi sono stati scaricati da pypi, una buona prassi è quella di sistemare i profili di disinstallazione dando un contributo alla comunità.
Di solito le risorse che sono registrate e non vengono disinstallate correttamente sono quelle gestite con i profili di GenericSetup, come per esempio dei CSS o javascript, ma anche controlpanel e skin layers. Per avere degli esempi di come eseguire una corretta disinstallazione, basta cercare diversi prodotti nella collective (ad esempio redturtle.smartlink).
Se malauguratamente il prodotto non mette a disposizione il repository con i sorgenti (e può capitare), o sistemare il profilo di disinstallazione risulta troppo complicato, si riescono a rimuovere parecchie risorse anche manualmente.
Tutte quelle relative a GenericSetup si possono rimuovere da ZMI nei vari tool, ma i nostri nemici più agguerriti sono state le persistent-utilities, che sono persistenti ma non si riescono a visualizzare da ZMI.
Nessun problema, ci sono venute in aiuto due preziose risorse:

• wildacard.fixpersistentutilities, un prodotto che aiuta a riconoscere e rimuovere da interfaccia utente eventuali persistent-utilities presenti nel sito
• un'utilissima guida di Nathan Van Gheem che spiega come rimuovere manualmente adapters, utility e subscribers.

Blob Blob Blob

Su Plone 4 è diventato di default il supporto ai blob, per ovvi motivi di miglioramento delle prestazioni e di separazione di file e immagini dal Data.fs vero e proprio.
Per questo motivo, la migrazione di Plone 4 include uno step apposito che provvede in autonomia a migrare i contenuti di tipo file e immagine presenti nel sito ai blob.
Se i vostri prodotti prevedono contenuti che contengono immagini o file, è buona norma dotarli del supporto ai blob (procedura spiegata in un paragrafo della guida alla migrazione precedente) e di una procedura che permetta di migrare a blob i contenuti già presenti nel sito (ovviamente post-migrazione a Plone 4). Un buon esempio è fornito da redturtle.smartlink.

E per finire... la migrazione

Arrivati a questo punto, dopo aver verificato che tutti i prodotti siano compatibili con Plone 4 e aver ripulito il nostro Data.fs, possiamo procedere alla migrazione vera e propria.
Non serve altro che copiare i nostri dati nel nuovo buildout, farlo partire e andare nella ZMI del sito da migrare: un testo avvertirà che il sito è obsoleto e va aggiornato. Seguendo il link si avrà la possibilità di eseguire la migrazione in due modi:

• dry-run, cioè eseguendo tutti i passi della migrazione, ma non committando le modifiche alla fine: serve se si vogliono prima fare delle prove
• migrazione vera e propria: esegue tutti i passi e, una volta terminati, committa le modifiche e le scrive nel db.

Ovviamente il tempo impiegato dipende da molti fattori, come per esempio la potenza della macchina, la dimensione del Data.fs e il fatto di avere già i file sui blob.
Non sempre la migrazione andrà a buon fine al primo colpo. Fortunatamente quasi sempre il traceback dei fallimenti ci dà buone informazioni su cosa è andato storto, in modo da poterlo sistemare e ritentare. Nella mia esperienza, spesso i problemi erano proprio con utility mal rimosse o classi non più trovate.

Alla fine di tutto il procedimento, quando avremo un sito aggiornato e funzionante, prima di effettuare i vari test è buona norma fare un giro nel pannello di gestione dei prodotti aggiuntivi, in modo da vedere se ci sono degli upgrade-step da lanciare per sistemare alcuni prodotti. Altra operazione importante da fare è il pack del db, perché consente di guadagnare diverso spazio, visto lo spostamento all’esterno di file e immagini.

Conclusioni

In conclusione, se si prepara per bene il db da migrare, rimuovendo correttamente tutti i componenti inutilizzati, il tool di migrazione funziona discretamente bene.

Abbiamo solo avuto alcuni problemi durante la migrazione dei blob di un sito, come riportato anche da Ross Patterson in un suo post. Dopo una lunga analisi, abbiamo notato che il poskey Error veniva lanciato durante il commit finale, ma non siamo riusciti (come l'autore) a risalire all'origine del problema. La soluzione è stata quella di effettuare dei commit intermedi alla fine della migrazione dei file e alla fine delle immagini, anziché alla fine di tutta la procedura.

Seguendo questa sorta di check-list, siamo riusciti a migrare abbastanza agilmente una ventina di siti, e l'abbiamo riutilizzata anche per successivi lavori.

Sarà perché nella mia esperienza ho affrontato vari corsi di formazione per sviluppatori Plone, sarà perché non tutto il codice è sempre pronto per essere rilasciato, una cosa è certa: il rapporto tra il neofita e il codice da lui sviluppato è piuttosto combattuto.

Partiamo con una carrellata di quello che potete fare (ma in gran parte non dovete) fino ad arrivare alla soluzione dei casi più delicati.

Sviluppo old-style

Nell'uso quotidiano di Plone, il nostro amico buildout ci ha abituati per anni all'uso della directory di develop (di solito, la directory src):

[buildout]
...
develop =
    src/my.package
    ...

Sebbene questo metodo oggi sia largamente superato (vedi mr.developer), la comunità Plone lo ha utilizzato per anni e c'è ancora tanta documentazione in giro che ne parla.

Per molti utenti che non hanno dimestichezza con l'installazione di mr.developer (prima che questo diventasse parte dei template di buildout Plone rilasciati) questo modo è quello "più semplice".

Semplicemente: funziona!

Versiona-che?

Ammettiamo che vi troviate nella situazione di cui sopra: qual è la cosa peggiore che potreste trovare in un buildout?
Semplice! L'assenza del versionamento del codice.

Mi è capitato diverse volte di trovarmi in questa situazione: il Cliente X chiama per mettere mano a un buildout in cui erano presenti prodotti legacy proprio all'interno della cartella src.
Nei casi peggiori, si tratta di codice non versionato. Eppure ci viene chiesto di mettergli mano e di apportare un qualche tipo di modifica!

A volte può capitare di accorgersi che nemmeno la configurazione del buildout sia sotto controllo di versione...

Spesso il cliente si sente sufficientemente al sicuro sapendo che ha "una copia da qualche parte" (quando va bene), eppure è difficile fargli capire che la soluzione "backup" non è tutto.

Probabilmente siamo passati tutti per questa fase (detta anche fase del "ero giovane, avevo bisogno di lavorare"), ma spero per voi l'abbiate abbandonata abbastanza in fretta.

Externals SVN

Prima dell'esplosione di popolarità di Git/Github, il software di versionamento del codice più in voga tra gli sviluppatori Plone è stato SVN.
Ne è riprova il fatto che, ancora oggi, la collective SVN è un repository piuttosto utilizzato, anche se la nuova collective, ospitata su GitHub, sta rapidamente prendendo piede.

Una delle caratteristiche di SVN era la possibilità di definire il contenuto di una directory sotto controllo di versione tramite la definizione di externals (svn:externals), ossia permettere di caricare nella directory una serie di altri sorgenti provenienti (volendo) anche da altri repository.

Una volta compresa l'importanza del versionamento, il Cliente X potrebbe davvero apprezzare il fatto di sapere che il suo buildout è stato versionato, e che il contenuto della directory src contenente il suo codice è controllato da svn:externals, così che il sorgente di ogni prodotto venga scaricato dal repository stesso del prodotto.

Un esempio del formato che questa proprietà dovrebbe avere per due ipotetici prodotti Plone:

my.package https://my.repository/svn/my.package/trunk
your.package https://your.repository/svn/your.package/trunk

Il tutto ora è piuttosto robusto. L'unico problema riguarda l'utilizzo del trunk dei prodotti.
Questo tipo di configurazione può andare bene per un ambiente di sviluppo, ma come possiamo configurare l'ambiente di produzione?

Il trunk è per definizione una versione instabile o comunque sempre aggiornata di un prodotto; la possibilità che, aggiornando l'installazione o effettuandone una replica su un nuovo server (magari in seguito ad un disaster-recovery del sistema), il codice possa cambiare o aggiornarsi in qualche modo, è piuttosto pericolosa.

Per mantenere le cose stabili, si dovrebbe quindi riferirsi ai tag dei vari prodotti:

my.package https://my.repository/svn/my.package/tags/1.2
your.package https://your.repository/svn/your.package/tags/1.4.1

Il problema ora diventa degli sviluppatori, che sarebbero obbligati a gestire manualmente il cambio di repository da tag a trunk.

Come soluzione, per un certo periodo, abbiamo sperimentato l'uso di un doppia directory dei sorgenti, una per i tag di produzione e una per lo sviluppo.

Diciamo quindi di avere un buildout con un production.cfg in questa forma:

[buildout]
...
develop =
    prod-src/my.package
    prod-src/your.package
    ...

...e un development.cfg così:

[buildout]

extends = production.cfg
...
develop +=
    src/my.package
    src/your.package
    ...

Le due directory prod-src e src venivano quindi configurate con due svn:externals differenti: uno che puntava ai tag (versioni stabili e di produzione) e l'altro alle versioni di sviluppo.

La situazione è solida, ma in presenza di molti prodotti personalizzati (10, 20, ...) questo sistema risente di lentezza in fase di aggiornamento.

Ci sono modi migliori: andiamo avanti.

infrae.subversion

L'approccio dell'uso di svn:externals aveva anche un altro aspetto negativo: i puristi (diciamo pure: i maniaci) di buildout amano controllare tutto nei propri file .cfg; nell'esempio al caso precedente viene lasciata un'importante parte della configurazione (quali sorgenti scaricare) a SVN.
In pratica, aprendo il file di configurazione buildout.cfg non siamo in grado di vedere dove e quali versioni dei prodotti stiamo utilizzando.

La recipe infrae.subversion faceva esattamente questo e per un breve periodo ha risentito di una certa popolarità: che cosa scaricare usando SVN veniva configurato in un file .cfg!

[svneggs]
recipe = infrae.subversion
location = src
urls =
    https://my.repository/svn/my.package/tags/1.2 my.repository
    ...

La cosa non è andata avanti per molto, per vari aspetti negativi dell'approccio tra cui la lentezza (maggiore che usando svn:externals) e la fragilità (spesso gli aggiornamenti non andavano a buon fine).

Dimentichiamoci quindi anche di questo approccio.

Habemus egg

Torniamo al principio:
L'uso della sezione develop del nostro buildout è stata prevista per lo sviluppo.

Rendiamoci conto che tutti questi problemi si hanno solo in presenza di codice non pubblicamente rilasciato e rilasciabile: un qualunque prodotto pubblico viene scaricato automaticamente dal Python Package Index e ci dobbiamo preoccupare del suo sorgente solo se intendiamo mettergli mano per svilupparlo.

La soluzione migliore, da tempo documentata, è:

• poter utilizzare un server pypi privato (aziendale o del cliente)
• rilasciare i prodotti nel formato standard python (gli egg per l'appunto).

Il primo caso è in realtà piuttosto semplice: un pypi server non è altro che una directory di file accessibile via Web/HTTP.

Ammettendo di avere una directory su un server privato e che questa directory contenga tutti i nostri egg, questo semplice comando Python lanciato sul server permetterebbe di avere un repository di egg compatibile con buildout:

$ cd pypi-archive
$ python -m SimpleHTTPServer 9000

A questo punto va indicato al buildout che esiste questa possibilità:

[buildout]
...
find-links =
    http://dist.plone.org/release/4.2.4
    http://dist.plone.org/thirdparty
    http://the.server:9000/

Ovviamente un modo più robusto sarebbe quello di configurare un vero web server, come Apache.

Il problema in questo caso è che l'egg, una volta generato, andrebbe copiato manualmente in questa directory, mentre l'uso del Python Package Index ci ha abituati a un automatismo a cui è difficile rinunciare.
Presto detto: se volete ottenere un server in stile pypi perfettamente funzionante, potete usare Plone stesso e il prodotto PloneSoftwareCenter (che supporta le Python Package Index API).

Ora il secondo problema: com'è fatto un egg? Come posso generarlo e rilasciarlo?

Se per anni il rilascio di egg (pubblico o privato che fosse) necessitava di conoscere almeno i rudimenti di distutils, oggi ci sono fantastiche utility che nascondono tutta la complessità. In questo stesso blog potete leggere una dettagliata descrizione del migliore di questi: zest.releaser.

Come potete leggere dall'articolo, zest.releaser si occupa di tutte quelle operazioni di versionamento del codice necessarie al momento di una nuova release (aggiornamento, tag della versione, ...) e lo fa per varie tecnologie di versionamento (SVN, Git, Mercurial, ...).

Sembrerebbe quindi che abbiamo trovato la soluzione migliore per i nostri prodotti proprietari:

• codice versionato
• buildout che usa mr.developer
• server pypi riservato
• uso di zest.releaser.

Ambienti poco amichevoli

Non abbiamo però definito che cosa si intende per "server pypi riservato". Questo può essere:

• un servizio pubblicamente accessibile ma protetto da autenticazione
• un servizio senza autenticazione, ma posto su rete interna del cliente o dell'azienda.

Nel primo caso, l'autenticazione può essere un problema: configurare buildout/Python perché richieda autenticazione non è esattamente triviale e può dare vari grattacapi.

Nel secondo caso tutto torna ad essere molto semplice, ma cosa succede se il servizio è nella rete interna del cliente e siete voi il fornitore che deve mettere mano al codice per poi rilasciare nuove versioni?
A meno di non possedere una VPN, la cosa non sta in piedi.

In più: ci sono situazioni in cui l'accesso alla rete dall'esterno (e a volte anche verso l'esterno) è fortemente limitato da policy di sicurezza e regole di firewall che farebbero impallidire lo scudo sulla luna boscosa di Endor.

La difficoltà di poter avere un repository di egg condiviso tra voi e il cliente può non essere banale.

Ci sono però alcuni prerequisiti su cui non si transige: i sistemisti avranno dovuto accettare per forza di cose che "Plone non viene distribuito con un CD ma viene installato accedendo alla Rete" e che "Il buildout usa un sistema di versionamento a cui gli sviluppatori devono poter accedere".

In questi casi limite, noi in RedTurtle abbiamo iniziato a usare un metodo forse non troppo pulito, ma semplice e senza controindicazioni.

Pypi-local!

L'idea è semplice:

• generare gli egg senza rilasciarli (ci piace rilasciare codice, ma non sempre si può)
• inserire gli egg nel buildout, in una directory
• versionare anche i sorgenti dell'egg.

"pypi-local" è stato il primo nome dato alla directory atta ad ospitare gli "egg locali", e da allora non è più cambiato (se in RedTurtle qualcuno dice "...è nella pypi-local" tutti capiscono!).

Tenendo fede a questo nome, ecco come configurare il buildout:

[buildout]
...
find-links =
    ./pypi-local
    http://dist.plone.org/release/4.2.4
    http://dist.plone.org/thirdparty

In pratica, nella radice del buildout deve esistere questa directory.

Prima di impallidire per la poca eleganza di questo approccio, sappiate che questo ci ha aiutato in molte situazioni, non ultimo il caso seguente: dare un prodotto (sempre non rilasciato pubblicamente, a volte per mere questioni di "non saprei se va bene per pypi") a un cliente con un livello tecnico minimo, limitato solo al "so lanciare un buildout".
Come? Si manda l'egg per e-mail, con due righe di istruzioni e il gioco è fatto.

rt.zestreleaser.pypilocal

Fermo restando che nessuno vuole abbandonare l'uso di zest.releaser, l'uso della directory locale richiede la perdita di un automatismo e una copia manuale dell'egg generato nella directory:

...
Register and upload to pypi (y/N)? 
Register and upload to plone.org (Y/n)? n
Register and upload to redturtle (Y/n)? n
...
INFO: Finished full release.
INFO: Reminder: tag checkout is in /private/var/folders/Ka/Ka7qqP8VFb8dZJO8sohbrE+++TI/-Tmp-/...

zest.releaser esegue una serie di operazioni automatiche per rilasciare gli egg su tutti i server configurati, ma alla fine ci dice dove possiamo trovare la copia temporanea usata per queste operazioni ("Reminder: tag checkout is in...").

Ci basta andare cercare il nostro egg dentro a quella directory (nella sottodirectory dist).

Semplice? Sì, ma rimangono due considerazioni:

• la programmazione fa l'uomo pigro
• zest.releaser è maledettamente ben fatto, ed è pluggabile.

Per questo motivo (sì, esatto, solo per non dover copiare manualmente l'egg) abbiamo reso disponibile un plugin per zest.releaser che permette di copiare automaticamente l'egg nella directory "pypi-local" (o in qualunque directory vogliate): rt.zestreleaser.pypilocal.

La sua configurazione è molto semplice: vi basta modificare il vostro file .pypirc nel seguente modo:

[distutils]
index-servers =
 pypi
 plone.org
 ...

[rt.zestreleaser.pypilocal]
pypi-local = ../../pypi-local
global = /opt/global-pypi

Nella sezione "rt.zestreleaser.pypilocal" dovete andare a specificare la directory (volendo anche più di una) che zest.releaser cercherà prima di chiedervi se intendete copiare lì i file.

L'esempio "../../pypi-local" non è casuale: se state usando un struttura di directory standard nel vostro buildout, quando lancerete i comandi di zest.releaser vi troverete dentro alla directory del vostro prodotto (solitamente qualcosa nella forma buildout-root/src/my.package). Il percorso relativo fornito rispecchia esattamente l'idea che la directory pypi-local sia nella radice del buildout.

L'output di zest.releaser cambierà in questo modo:

...
Register and upload to pypi (y/N)? 
Register and upload to plone.org (Y/n)? n
Register and upload to redturtle (Y/n)? n
Copy egg to folder ../../pypi-local (Y/n)? 
Copy egg to folder /opt/global-pypi (Y/n)? n
...
INFO: Finished full release.
INFO: Reminder: tag checkout is in /private/var/folders/Ka/Ka7qqP8VFb8dZJO8sohbrE+++TI/-Tmp-/...

Conclusione

Tra tutti i metodi descritti, spero ne abbiate trovato almeno uno che si adatti alle vostre esigenze.

Gli strumenti per fare le cose nel modo giusto e per evitare il caos nella gestione dei vostri add-on Plone ci sono tutti, e sono semplici da usare!

L'immagine in testata è di fifthconspiracy.

Some time ago I came across a tweet that talked about Meteor and, as usual, I tried to investigate the simple reading.

Meteor runs on Node.js. Has it's own server

First, install Meteor downloading the installer (in my case, on an old Windows XP machine - yes, there is also for Windows!).

Completed the first step, go to the installation folder of Meteor and create the application.

Now, let's create pages, css and javascript files. Basically, file are structured in three folders:

• client
• server
• public.

Meteor uses MongoDB, through Javascript API called "collection"

All files in client directory are served only to clients (server doesn't know about them), files in public are resources most of the time, i.e. images. Server directory serves data to server. Everything outside those folders is shared between clients and server (it would be a good place to put scripts or templates to run on both, server and client, more about that other time). In our simple program we are going to use only client directory.

helloworld.css

html {margin:0;background-color: #eee;}

body {
width: 640px;
margin:auto;
text-align: center;
font-family: 'Helvetica';
color: #aaa;
text-shadow:1px 1px #fff;
}

p {font-style: italic}

helloworld.html

<head>
 <title>Hello World</title>
</head>
 
<body>
<h1>Hello</h1>
<p>My very first application</p>
<div style="float:left;width:49%;text-align:left">{{> hello}}</div>
<div style="float:right;width:50%;text-align:left"> 
{{> form}}<br><br>
{{> anotherform}}
</div>
</body>
 
<template name="hello">
 {{somebody}}
</template>
 
<template name="form">
<input id='newName' type='text'/><input type='submit' value='Set!'/>
</template>

<template name="anotherform">
 <input id='newNameAppend' type='text'/><input type='submit' value='Append!'/>
</template>

helloworld.js

Session.set( 'somebody' , '' );
 
Template.hello.somebody = function(){
    return Session.get('somebody');
}
 
Template.form.events({
     'click input[type=submit]': function(){
     Session.set( 'somebody' , $('#newName').val() );
}
 
});

Template.anotherform.events({
     'click input[type=submit]': function(){
     Session.set( 'somebody' , Session.get( 'somebody') +'\n'+ $('#newNameAppend').val() );
}
 
});

css file is trivial, the most important things are about html and js file.

Let's get straight to the .html, that could be put there whatever you would like to render. Just without links to CSS and/or other scripts. If needed to include something, just copy file inside file structure (client, server, public or root of your project) and Meteor will minify it and include along other files.

Furthermore, html is written in Handlebars syntax, a powerful templates for javascript.

Inside curly brackets you put names of variables (somebody) or templates (> hello). ">" sign means that you are including a template. In our case we are including hello, form and anotherform templates which definitions you can find between template tags.

Let's talk about .js: In helloworld.js we set up a default value (void) for our session variable

Session.set( 'somebody' , '' );

Now that we have a variable inside a session, our template can use it to display

Template.hello.somebody = function(){
return Session.get('somebody');
}

All templates you setup are available in a namespace Template. In this case we have Template.hello, Template.form and Template.anotherform already defined for us by Meteor. To use {{somebody}} in the template, we must define that variable to get a proper display. We make it a simple function that returns our session value with Session.get('somebody').

Finally, let's talk about onclick events:

Template.form.events({
 'click input[type=submit]': function(){
 Session.set( 'somebody' , $('#newName').val() );
 }
});

Template.anotherform.events({
     'click input[type=submit]': function(){
     Session.set( 'somebody' , Session.get( 'somebody') +'\n'+ $('#newNameAppend').val() );
}
});

Using Template namespace we are reaching form and anotherform template. The first sets and displays the value submitted in text field, the second appends to present values just submitted. To handle events we put an object with definition inside an event function.

Template.form.events( {} );

That's it! Notice that each time we edit a file, no reload of our page is needed: it's automatically updated "on-the-fly".

This is a screenshot of the whole application, very simple but, IMHO, very clear. Stay tuned for something more complex about Meteor application in next posts.

To let a linux server connect with Forefront I wanted to set up and run cntlm, which is a local proxy that authenticates to a Forefront gateway to allow internet traffic.

The server was offline, I had to think about an offline method to install cntlm. I downloaded the deb from http://ftp.debian.org/pool/main/c/cntlm/cntlm_0.35.1-5_i386.deb and saved it on a USB pen drive, then installed the deb with dpkg:

dpkg - i cntlm_0.35.1-5_i386.deb

Once I got cntlm installed I tested my Forefront connection parameters using the "magic" -M flag:

cntlm -fv -l $PORT -u $USER@$DOMAIN -p $PASSWORD \
      -w $NETBIOS_NAME -M $URL $TGMIP $TGMPORT

This will gave me hints to edit /etc/cntlm.conf file properly in order to run cntlm in daemon mode.

I had just a debian network install cd with me and I asked Loca if she wanted some.

A short explanation of the arguments in the command line follows:

• -fv run cntlm in foreground and verbose mode
• -l $PORT listen to the specified port (default 3128)
• -p $PASSWORD you should know it...
• -u $USER@$DOMAIN the user that authenticates to Forefront (e.g. alert@redturtle)
• -w $NETBIOS_NAME the workstation NetBIOS name (e.g. REDTURTLE)
• -M $URL probe a test url to make "magic detection" (e.g. http://www.example.org)
• $TGMIP the Forefront gateway ip address (e.g. 10.0.0.10)
• $TGMPORT the port Forefront gateway is listening to (e.g. 8080)

More information on the cntlm man page (check out the online version).

Environment variables

With cntlm up and running daemonized by the init scripts, to use the proxy I had to define the proper environment variables:

export http_proxy=http://127.0.0.1:3128
export https_proxy=http://127.0.0.1:3128
export ftp_proxy=http://127.0.0.1:3128 

apt

I had also to setup apt, adding a file /etc/apt/apt.conf.d/02proxy containing those lines:

Acquire::http::proxy "http://localhost:3128/";
Acquire::ftp::proxy "ftp://localhost:3128/";
Acquire::https::proxy "https://localhost:3128/";

Source: http://askubuntu.com/questions/89437/how-to-install-packages-with-apt-get-on-a-system-connected-via-proxy

Subversion

To use svn for checkouts I had to look in /etc/subversion/servers for the "[Global]" section and added a couple of lines like in this example:

[Global]
...
http-proxy-host=localhost
http-proxy-port=3128
... 

Source: http://stackoverflow.com/questions/82530/svn-over-http-proxy

Buildout

After a few moments we were friends and decided to join our efforts from freedom.

Once I apt-got all the packages I needed and checked out my Plone buildout I thought everything would be fine.

Of course I was wrong!
There's an issue, apparently with urllib, that makes buildout fail (see https://bugs.launchpad.net/zc.buildout/+bug/484735, https://github.com/buildout/buildout/issues/32).

I forked buildout on github to work around this issue.

You can clone https://github.com/ale-rt/buildout/tree/issue-32 and can get the source tarball from https://github.com/downloads/ale-rt/buildout/zc.buildout-1.6.4-issue-32-1.tar.gz.

To use it I suggest you to create a virtual env in your buildout directory, add in the buildout root a folder (e.g. pypi-local), download to that folder the tarball and "pip install" it, the commands are something like:

virtualenv cntlm
cd cntlm/
. bin/activate
mkdir pypi-local
cd pypi-local/
wget https://github.com/downloads/ale-rt/buildout/zc.buildout-1.6.4-issue-32-1.tar.gz
cd ..
./bin/pip install pypi-local/zc.buildout-1.6.4-issue-32-1.tar.gz 

To use this folder as a local pypi repository in your buildout, edit your buildout configuration file and add to the find-links this folder. Don't forget to pin the zc.buildout version!

[buildout]
...
find-links = 
    ...
    file://${buildout:directory}/pypi-local
    ...

[versions]
...
zc.buildout = 1.6.4-issue-32-1

With this setup buildout runs fine :)!

Check_mk scan_port plugin

The reason of this choice is because most of them make use of system tools in order to perform port scan action. There is no problem with that, tools like nmap are really commons, but what I want is avoid any kind of dependence.

Moreover I prefer have control on the code since the beginning mainly because I can choose the programming language ;)

The code

Check_port plugin is written in Python and it uses only the standard library thus it should be portable as long as you have Python installed on your system.

The code is quite simple, for each given port the program test if the connection is active.

Usage

# Scan for port 22 and 25 on a remote server 192.168.1.100
./check_ports.py -o 192.168.1.100 -p 22,25

./check_ports.py -o 188.165.195.56 -p 22
OK; opened 22 ; closed

./check_ports.py -o 188.165.195.56 -p 23
CRITICAL; opened  ; closed 23

Check_mk configuration

# 'check_ports'
define command{
  command_name check_ports
  command_line $USER1$/check_ports.py -o $ARG1$ -p $ARG2$ 
}

(( "Check_ports!127.0.0.1!22,23", "Check ports", False), ['host'])

Note: be sure you are not blocked by a firewall.

Next step: we imported the resources you need to Twitter Bootstrap within the Domino project:

And finally, we have created an XPages with the following source code:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
    <xp:this.resources>
       <xp:styleSheet href="bootstrap.css"></xp:styleSheet>
       <xp:styleSheet href="bootstrap-responsive.css"></xp:styleSheet>
       <xp:metaData name="viewport" content="width=device-width, initial-scale=1.0">
       </xp:metaData>
    </xp:this.resources>
    <!-- NAVIGATION BAR -->
    <br/><br/>
  <xp:panel styleClass="navbar navbar-inverse navbar-fixed-top">
    <xp:panel styleClass="navbar-inner">
    <xp:panel styleClass="container">
    <xp:panel styleClass="row">
    <xp:panel styleClass="span4">
      <xp:label id="label1">
        <xp:this.value><![CDATA[#{javascript:"Welcome " + @Name("[CN]",@UserName())}]]></xp:this.value>
      </xp:label>
    </xp:panel>
    <xp:panel styleClass="span6">
      <ul class="nav nav-pills">
       <li class="dropdown">
         <a class="dropdown-toggle" data-toggle="dropdown" href="#">
           <i class="icon-white icon-file"></i> Dropdown <b class="caret"></b>
         </a>
         <ul class="dropdown-menu">
           <li><a tabindex="-1" href="#">Action</a></li>
           <li><a tabindex="-1" href="#">Another action</a></li>
           <li><a tabindex="-1" href="#">Something else here</a></li>
           <li class="divider"></li>
           <li><a tabindex="-1" href="#">Separated link</a></li>
         </ul>
      </li>
     </ul>
    </xp:panel>
    <xp:panel styleClass="span2">
      <xp:label value="Logout" id="label3"></xp:label>
    </xp:panel>
   </xp:panel>
  </xp:panel>
 </xp:panel>
 </xp:panel>
 <!-- APPLICATION LAYOUT -->
 <xp:panel styleClass="subhead">
   <xp:panel styleClass="container">
     <xp:panel styleClass="row">
       <xp:panel styleClass="span4">
        <ul class="nav nav-list sidebar-nav-fixed">
          <li class="nav-header">List header</li>
          <li class="active"><a href="#"><i class="icon-white icon-home"></i>Home</a>
          </li>
          <li><a href="#"><i class="icon-book"></i>Library</a></li>
          <li><a href="#"><i class="icon-pencil"></i>Applications</a></li>
          <li class="nav-header">Another list header</li>
          <li><a href="#"><i class="icon-user"></i>Profile</a></li>
          <li><a href="#"><i class="icon-cog"></i>Settings</a></li>
          <li class="divider"></li>
          <li><a href="#"><i class="icon-flag"></i>Help</a></li>
        </ul>
       </xp:panel><br/>
       <xp:panel styleClass="span8">
         <xp:table>
           <xp:tr>
            <xp:td><xp:label value="First Name" id="label2"></xp:label></xp:td>
            <xp:td><xp:inputText id="inputText1"></xp:inputText></xp:td>
           </xp:tr>
           <xp:tr>
            <xp:td><xp:label value="Last Name" id="label4"></xp:label></xp:td>
            <xp:td><xp:inputText id="inputText2"></xp:inputText></xp:td>
           </xp:tr>
           <xp:tr>
            <xp:td><xp:label value="Address" id="label5"></xp:label></xp:td>
            <xp:td><xp:inputTextarea id="inputTextarea1"></xp:inputTextarea></xp:td>
           </xp:tr>
           <xp:tr>
            <xp:td><xp:label value="Phone" id="label6"></xp:label></xp:td>
            <xp:td><xp:inputText id="inputText3"></xp:inputText></xp:td>
           </xp:tr>
         </xp:table>
       </xp:panel>
      </xp:panel>
     </xp:panel>
    </xp:panel>
  <script type="text/javascript" src="js/jQuery-1.8.0.min.js" clientSide="true"></script>
  <script type="text/javascript" src="js/bootstrap.js" clientSide="true"></script>
</xp:view>

This is what you get on the page number from the web:
Of course, nothing prevents you from using any other responsive layout: Twitter is only one of the choices!

 // Tramite jQuery si prende la lingua corrente dall'attributo del tag html 
 var lang = jq('html').attr('lang');

 // si dichiara il vocabolario con le traduzioni nelle varie lingue
 var messages = {'it': 'Benvenuti',
                 'en': 'Wellcome',
                 'es': 'Bienvenido',
                 'fr': 'Bienvenue'};

 // apriamo l'alert scegliendo la traduzione opportuna.
 alert(messages[lang]);

Se la pagina web che stiamo creando ha molte parti caricate via javascript, e quindi molti testi e parole da presentare tradotte, questo approccio è scomodo; innanzitutto perché si rischia di dover mantere molto codice solo per le traduzioni.
Se siamo in un caso come questo, il sito sviluppato probabilmente è già multilingua e i dati verranno presentati correttamente. Per quanto riguarda i testi da mostrare in javascript, è meglio sfruttare un motore di traduzioni, e in Plone, grazie alla community, un'utility di questo tipo esiste già: jarn.jsi18n. Grazie a questo prodotto, infatti, è possibile sfruttare appieno il message factory di plone e tutti i suoi file di traduzioni.

Come usarlo

Il funzionamento è semplice. Una volta installato il prodotto nel sito, tutto quello che dobbiamo fare è caricare un catalogo e creare un message factory nel javascript che scriviamo:

 // Tramite jQuery si ottiene la lingua corrente dall'attributo del tag html
 var lang = jq('html').attr('lang');
  
 // Dato un dominio di traduzioni e una lingua si ottiene un catalogo dal server;
 // questo restituirà al browser un vocabolario tipo
 // {..."from_date": "Dal", "to_date": "Al", ...}
 jarn.i18n.loadCatalog('fta.at', lang);
 
 // Creiamo un message factory javascript che sfrutta il catalogo restituito dal server
 mf = jarn.i18n.MessageFactory('fta.at');
 

Da qui in poi si potrà procedere utilizzando il message factory in modo molto 'plonish':

 // Si può iniziare a tradurre stringhe
 > mf('How to get here'):
 "Come arrivare"

E se abbiamo dei testi da costruire dinamicamente: 

 
 // Si possono tradurre anche stringhe in modo più dinamico, esattamente come in plone.
 > mf('other_results');
 "... e altre ${results} voci"

 > mf('other_results', {'results': 10});
 "... e altre 10 voci"

Under the hood

Come funziona tutto questo? Guardando il codice, ci si può rendere conto di come cose utili e funzionali possano essere create in modo semplice. Il pacchetto si compone di una vista e di un javascript. La vista è una classica BrowserView Plone che restituirà una stringa json con i dati richiesti:

 
 def __call__(self, domain, language):
     ...

     # Si ottiene l'utility plone per le traduzioni
     td = queryUtility(ITranslationDomain, domain)
     if td is None or language not in td._catalogs:
         return

     # Si ottiene il catalogo per il dominio nella lingua richiesta
     mo_path = td._catalogs[language][0]
     catalog = td._data[mo_path]._catalog
     if catalog is None:
         td._data[mo_path].reload()
         catalog = td._data[mo_path]._catalog
     ...

     # si restituisce il catalogo in formato json. 
     # Qualcosa del tipo: '{..."from_date": "Dal", "to_date": "Al", ...}'
     response.setBody(json.dumps(catalog))
     return response

Il javascript si occupa della chiamata al server per ottenere il catalogo che verrà gestito interamente lato client: una cosa molto interessante in questa gestione è, nei browser che lo consentono, l'uso dello storage del browser, tramite cui si riesce a fare caching di questo catalogo e non ricaricarlo ogni volta che si chiama una pagina:

 
 // si salva il catalog nello storage con una chiave associata
 var key = domain + '-' + language;

 // se abbiamo già quella chiave nello storage verificheremo se il catalogo è ancora valido.
 if (key in localstorage) {
     if ((Date.now() - parseInt(localstorage.getItem(key + '-updated'), 10)) < ttl) {
         var catalog = JSON.parse(localstorage.getItem(key));
         jarn.i18n._setCatalog(domain, language, catalog);
         return;
         }
     }

Come sempre, conoscere bene l'architettura e i componenti di Plone permette di svolgere lavori più o meno complicati in modo semplice, ma soprattutto pulito.

"Quei content-type sono vecchi... cambiamoli!"

Su alcuni portali avevamo una serie di content-type creati ad hoc per esigenze passate, poi diventati obsoleti o perché le funzionalità sono state implementate (meglio) in altri prodotti, o perché non abbiamo più bisogno di loro.
Per esempio, avevamo creato diversi content-type che aggiungevano funzionalità a quelli base di Plone (al tempo non conoscevamo ancora la potenza di archetypes.schemaextender) sovrascrivendoli, e ora dovevamo tornare indietro per poter ricominciare a utilizzare le versioni base.

Tornare a utilizzare le versioni standard è semplice, basta disinstallare il nostro prodotto.
Cosa fare però con i contenuti già creati? Come torniamo a una situazione "standard" senza rompere niente?
E' come avere tra le mani una serie di cubi avendo a disposizione solo buchi tondi: non funzioneranno più, ma non li possiamo perdere. Vanno sostituiti.

La soluzione è facile: li migriamo!

Vediamo ora come creare una procedura di migrazione.

Definizione della procedura

def makeTypeMigrator(context, src_type, dst_type):
    """ generate a migrator for the given at-based portal type """
    from Products.contentmigration.archetypes import InplaceATItemMigrator

    class ATItemMigrator(InplaceATItemMigrator):
        src_portal_type = src_type
        src_meta_type = src_type
        dst_portal_type = dst_type
        dst_meta_type = dst_type

    return ATFolderMigrator

def migrateOldContentType(context):
    from Products.contentmigration.walker import CustomQueryWalker
    migrator = makeTypeMigrator(context, 'OldPortalType', 'NewPortalType')
    walker = CustomQueryWalker(context,
                               migrator,
                               src_portal_type="OldPortalType",
                               dst_portal_type="NewPortalType",
                               use_savepoint=True,
                               query={'path': '/siteid/folder-1'})
    walker.go()
    return walker.getOutput().splitlines()

In questo esempio abbiamo un metodo "makeTypeMigrator" che, quando viene chiamato, crea una classe che eredita da InplaceATItemMigrator (classe che permette di rimpiazzare il vecchio content-type con il nuovo, sostituendolo in tutto e per tutto) alla quale serve sapere solamente qual'è il tipo di origine e quello di destinazione.

Il metodo "migrateOldContentType", invece, è quello che si occupa di preparare e svolgere a tutti gli effetti la migrazione.
Per effettuare la migrazione servono 2 cose: il migrator (oggetto che si occupa di tutte le operazioni di migrazione) e un walker. Il walker serve per navigare attraverso il catalogo ed effettuare la migrazione ad ogni elemento che trova.

Come si può vedere, gli vengono passati diversi parametri come il migrator, appunto (per la procedura di migrazione) e i vari content-type (quello di partenza viene utilizzato per fare una ricerca in catalogo, se non si passano ulteriori parametri).

Ci sono poi diversi altri parametri opzionali, per esempio la possibilità di usare dei savepoint e di definire una query per la ricerca in catalogo più sofisticata.
Si può anche impostare un metodo da richiamare prima di migrare ogni risultato trovato (attraverso l'attributo "callBefore") per fare alcune operazioni o controlli ulteriori (se questo metodo ritorna False, il contenuto non viene migrato).

A questo punto, basta solamente richiamare il metodo "migrateOldContentType" per lanciare la procedura. Questo ci ritorna le informazioni di tutte le operazioni effettuate, quindi è anche possibile mostrarle all'utente (stampandole nel log, per esempio).

messages = migrateOldContentType(portal)
 for m in messages:
    logger.info(m)

Funzioni aggiuntive

Operazioni post-migrazione

Come abbiamo visto, con l'attributo callBefore è possibile eseguire operazioni prima della migrazione. Ma è anche possibile eseguire operazioni appena dopo la migrazione.
Per fare questo, basta creare dei metodi dentro alla classe ATItemMigrator i cui nomi inizino con "last_migrate_".
Questi metodi verranno richiamati una volta completata la migrazione di un contenuto, e si avranno a disposizione sia il vecchio oggetto (self.old) che quello nuovo (self.new).

Migrazione di oggetti folderish

L'esempio di prima era riferito ad Archetypes semplici. Se si vogliono migrare degli oggetti folderish bisogna utilizzare la classe InplaceATFolderMigrator.

Nota Bene: nelle versioni compatibili per Plone 3.3.5 (fino alla 2.0.1), la migrazione delle cartelle ha dei problemi e non funziona correttamente.

Migrazione di campi

E' anche possibile effettuare una migrazione di campi all'interno di un Archetype. Ciò è utile, per esempio, quando si deve cambiare il nome, lo storage o effettuare delle modifiche ai valori memorizzati.
Per usare questa funzionalità basta utilizzare la classe InlineFieldActionMigrator.

Conclusioni

In conclusione, questo è un ottimo tool che permette di effettuare operazioni complesse scrivendo pochissime righe di codice.

Come abbiamo visto, ha anche parecchie funzioni che permettono di creare procedure altamente personalizzate in base ai propri bisogni.