The task was simple - import to Plone 36.000 documents (with all children it gives the total of 120.000 objects). Simply creating it using invokeFactory will take too much time (aprox. 14 hours). Why not create just brains and let users decide which document fully migrate? This is what we did.

We started with import script which creates brains in portal_catalog using directly catalog_object method:

pc = getToolByName(self.context, 'portal_catalog')
pc.catalog_object(dummy_object, dummy_object.path)

dummy_object is a simple python object with all metadata that we need later for portal_catalog query:

>>> pp dummy_object.__dict__
{'title': u'dummy title',
'id': u'simple_id',
'review_state': 'private',
'path': '/plone/importfolder/ToBeMigrated_simple_id'}

After lunching the script (it took 19 minutes) we had all the brains (36.000) in portal_catalog with proper metadata/index updated. Now we need to allow users to see them. So we created traverser for our importfolder:

def __bobo_traverse__(self, REQUEST, name):
    if name.startswith('ToBeMigrated'):
       view = getMultiAdapter((self, self.REQUEST), name='to_be_migrated')
       view.setBrainId(name)
       return view
    return super(ImportFolder, self).__bobo_traverse__(REQUEST, name)

which returns a simple BrowserView with the brain.id. The view has a template which informs end-user that this document need to be migrated. If he decided to import it - system will start import process for selected brain.id.
The rest is pure Plone folder_contents view which lists my 'dummy' brains in import_folder (cause the path in the brain is correct). Simple and much faster ;-)

Introduzione

L'idea che sta dietro al progetto nasce dalla "lentezza" di Plone in tutte quelle situazioni in cui è necessario effettuare data-entry massivo e/o ripetere molto spesso la stessa operazione.

Non si sta quindi parlando di rendere Plone più veloce (il Web è pieno di sanguinose discussioni a riguardo!) ma di rendere l'interfaccia più semplice. A volte bastano pochi accorgimenti.

Un esempio semplice, ma che fa capire quello che intendo è la PLIP 228 discussa per Plone 4. Si parla di ripristinare il menù a tendina "Aggiungi nuovo elemento" anche per i contenuti che non sono cartella (rimosso con l'avvento di Plone 2.5). I motivi che hanno portato alla sua rimozione sono tutto sommato buoni (legati all'usabilità dell'interfaccia) ma tutti si sono accorti quanto fosse più facile prima (leggasi "meno click e meno caricamenti") inserire più contenti in modo massivo.
Un'interfaccia più ricca è anche più potente, ma porta anche a svantaggi dovuti alla sua minore facilità. Qual'è il confine?

In questo caso, e nei casi di cui questa serie di prodotti vuole occuparsi, la questione è ovviamente un appesantimento dell'interfaccia che diventa meno semplice, meno chiara...
Ad ogni modo non è sempre sbagliato fornire (a chi la vuole) un'interfaccia più complessa, che magari necessita l'utente/redattore ad un addestramento maggiore, ma che può portare a anche a ridurre il numero di caricamenti.

Esempio numero 1: le briciole di pane

Cosa non va nelle briciole di pane di Plone? Ovviamente nulla!

Chiari, semplici, leggibili link che permettono di tornare velocemente ai contenitori del documento corrente...

Quando un utente usa le briciole di pane?
Un utente visitatore le usa per tornare al contenitore... nulla di più, e non ci si aspetta quindi che siano necessarie altre funzionalità.
Trovo il comportamento attuale un po' limitante invece per gli utenti redattori... questi possono voler tornare al contenitore/i per effettuare altre operazioni, che a mio parere possono essere:

• Modificare il contenuto
• Accedere alla vista dei contenuti della cartella
• Aggiungere nuovi elementi

redturtle.speedupui.pathbar

Il primo (e speriamo non l'ultimo) prodotto si occupa ovviamente della pathbar di Plone che non a caso ho portato come esempio.

SpeedUpUI Pathbar sostituisce la normale viewlet delle briciole di pane con una versione più complessa che offre un menù a tendina ai redattori, per effettuare le operazioni descritte sopra.

La versione 0.1.0dev non supporta ancora la gestione dell'aggiunta di nuovi elementi (ammettiamolo... probabilmente sarebbe la modifica più interessante... date tempo al tempo!) così come non c'è un effettivo controllo dei permessi (perché mostrare un link "modifica" se l'utente non ha effettivamente il permesso di farlo?), ma ha offerto comunque interessanti spunti per fare riflessioni...

Innanzi tutto l'elemento corrente delle briciole di pane non ha nessuna funzionalità avanzata. Se si vuole modificare il contenuto corrente Plone offre già un apposito comando.

Per quali contenuti poi mostrare la voce "Contenti" per visualizzare i contenuti della cartella?

In un primo momento verrebbe da pensare tutti. Ovviamente tutti gli elementi della pathbar tranne l'ultimo sono sicuramente contenitori. Ad ogni modo ci sono casi in cui il contenitore è stato scritto per non sembrare tale... L'unico esempio vivente che ho visto usare questa funzionalità è l'oggetto PoiIssue del gestore di segnalazioni Poi.

Gli oggetti di questo tipo utilizzano l'interfaccia INonStructuralFolder. L'uso di questa interfaccia viene utilizzato da Plone per capire se la cartella deve in effetti sembrare una cartella agli occhi dell'utente (deve avere una scheda per visualizzare i contenuti?).
Martin Aspeli ha scritto un vecchio tutorial ancora valido a riguardo.

La scelta è stata quindi quella di non mostrare il comando di visione dei contenuti per i contenuti INonStructuralFolder.

Conclusione

Il prodotto non è completo, forse migliorabile (di certo per quanto riguarda l'interfaccia mostrata) e probabilmente qualche altra buona funzionalità potrebbe essere implementata.

La scelta di usare un namespace di secondo livello speedupui nasce da un fatto preciso: ci sono altri "pezzi" del puzzle Plone che possono mostrare funzionalità aggiuntive che permettano di ridurre i caricamenti...

Un esempio?
Il navigatore...