It is the second time in a couple of days that I am asked why in some pages there is no link to the @@manage-portlets view. In both cases the archetypes missing the link (and the view) where inheriting from a very basic object.

After a small research I found that this view is registered for the interface plone.portlets.interfaces.ILocalPortletAssignable.

Making the object interface inherit from this interface solved the problem.

La Regione Emilia Romagna sta lavorando alacremente al miglioramento dell'accessibilità e dell'usabilità di Plone.

Dato che il futuro dell'editor WYSIWYG in Plone non è più Kupu (difficilmente personalizzabile e non troppo supportato) ma TinyMCE, già da tempo la scelta è stata di passare a TinyMCE anche nella versione 3 di Plone, usata in vari siti regionali.

Migliorare TinyMCE è più semplice che Kupu e lo dimostra come è stato possibile da parte nostra aumentarne le funzionalità per venire incontro ad alcune delle richieste della Legge Stanca (modifiche di cui si è discusso in un altro post, e ora integrate nella release ufficiale già dalla versione 1.1rc9); Altro particolare: trovo importante che questo editor esista anche come progetto indipendente.

Altre novità: la gestione dei link

Una richiesta recente per aumentare l'usabilità dei documenti è stata la seguente:

Modificare Plone in modo che i link interni, se fatti a contenuto di tipo File, mostrino l'icona del tipo di contenuto e la dimensione del file stesso

Una simile modifica aumenta l'usabilità generale della pagina, nonché impatta col Requisito 19 della Legge Stanca.
Dopo una prima analisi è risultato chiaro come fosse necessario scrivere un nuovo plugin per TinyMCE.

Come funziona collective.tinymceplugins.advfilelinks?

Il prodotto rilasciato fornisce il minimo delle modifiche possibili a TinyMCE (ma non minime quanto avrei voluto... ne parliamo dopo). Si tratta di un un plugin aggiuntivo (e per fortuna la presenza di plugin è prevista non solo dall'editor ma anche dalla sua configurazione di Plone) che sostituisce quello predefinito di Plone per i link interni (dal nome autoesplicativo plonelink).

Dopo un'analisi attenta di come poter ottenere le funzionalità richieste e della flessibilità delle API di TinyMCE, su indicazione della Regione stessa abbiamo preso la seguente strada, forse un po' limitata ma di minimo impatto sullo sviluppo e con una resa eccezionale se il browser è aggiornato:

• I link a file acquisiscono un nuovo attributo type (previsto dallo standard HTML anche se poco conosciuto) ed viene fornito un CSS aggiuntivo contenente varie regole per fornire l'icona.
  Esempio:
  

  a[type='application/pdf'] {
      background: url(pdf.png) no-repeat 0 50%;
      padding-left: 20px;
  }

  Questo tipo di regola CSS ha un buon supporto (da Internet Explorer 7 in poi).
• La dimensione del file è prima di tutto inserita nel title del link (che normalmente il plugin originale non fornisce) ma un buon effetto è ottenuto associando una ulteriore regola CSS:
  

  a.internal-link-tofile:after {
  	content: " ("attr(title)")";
  }

  Questa magica regola CSS (fa parte dello standard CSS 2, per quanto Internet Explorer la supporti solo dalla versione 8 in poi) inserisce del testo aggiuntivo dopo i link con classe internal-link-tofile.
  Il contenuto di questo testo è preso dall'attributo title, ma vi vengono aggiunte delle parentesi. Ovviamente questa classe CSS aggiuntiva è inserita dal nostro plugin in aggiunta alla già nota internal-link.

L'ultima funzionalità è forse la più interessante e per quanto il metodo usato sia davvero poco invasivo e l'effetto finale a dir poco bello, il limite ad avere Internet Explorer 8 è ancora grande.
E' comunque sopportabile? Sì, dato che l'attributo title rimane comunque disponibile agli utenti (e agli Screen Reader) in tutti i casi.

Note tecniche di estendibilità

TinyMCE per Plone sfrutta chiamate AJAX per richiedere al server informazioni sui contenuti. Come sempre le modifiche lato server sono minime e perfettamente integrate con quanto Plone già fornisce.

E' bastato fornire un nuovo adapter.

  <adapter
        for="Products.ATContentTypes.interface.IATFile"
        provides="Products.TinyMCE.adapters.interfaces.JSONDetails.IJSONDetails"
        factory=".adapters.JSONDetails"
        />

Grazie alla ZCA, questo adapter aggiuntivo interviene solo per i contenuti di tipo File o sottotipi (a volte ho l'impressione che senza adapter i plonisti non vivrebbero più!).

I problemi maggiori sono lato client... L'idea sarebbe come sempre estendere e non sovrascrivere. In un mondo perfetto questo plugin si sarebbe dovuto integrare con quello preesistente, sfruttandone tutto il codice presente.

Non mi è ancora chiaro se questo non è stato possibile per limiti miei, del plugin stesso, o di TinyMCE, ma il risultato per quanto funzionante è anche una copia di molti dei file originali (una forma di branch del plugin)... probabilmente non dormirò di notte per aver dovuto copiare i file di lingua... ma dopo tutto è una versione alpha!

Il limite maggiore di TinyMCE attualmente è che non usa jQuery (per quanto ci sia un progetto che integra jQuery e TinyMCE) e soprattutto che non c'è uso di eventi Javascript.

Sarebbe stato bello (ma che dico bello! Utile) se al click del mouse sul pulsante radio che seleziona un file piuttosto che un qualunque altro documento a cui associare il link, venisse lanciato un evento Javascript... evento al quale un buon plugin per jQuery avrebbe potuto reagire per eseguire azioni...

Per ora questo non pare possibile, ma sarebbe un buon passo avanti per TinyMCE.

Nota sul namespace

Sono rimasto colpito nel vedere come sulla collective ci siano così pochi plugin the TinyMCE (l'unica eccezione pare essere collective.tinymcetiles). Ci sono state sanguinose discussioni in passato sull'uso di namespace a 2 o 3 livelli (ne ricordo una completa e interessante). In questo caso l'uso dei 3 livelli mi è parso opportuno.

Spero che in futuro altri contribuiscano al gruppo di plugin collective.tinymceplugins e figli!

Riferimenti

• Plugin su plone.org
• Plugin su Python Cheeseshop

With the newest version of munin.zope you have 4 different plugins:

• ZServer threads
• ZODB activity
• Zope cache parameters
• Zope memory usage
  
  

Using aggregation you can end like this:

What it does? It takes data from multiple zeoclients (in this case every project from A-E have 4 zeoclients) and renders only total amount per project.
Here is munin.conf which does this trick:

[Server1;projectA]
  address 127.0.0.1
[Server1;projectB]
  address 127.0.0.2
[Server1;projectC]
  address 127.0.0.3
[Server1;projectD]
  address 127.0.0.4
[Server1;projectE]
  address 127.0.0.5

[Server1;Aggregated]
  update no
  total_memory.update no
  total_memory.graph_category Zope
  total_memory.graph_title Aggregated Zope memory
  total_memory.graph_order \
    projectA \
    projectB \
    projectC \
    projectD \
    projectE

  total_memory.projectA.sum \
    projectA:projecta_zopememory_instance_1.VmSize \
    projectA:projecta_zopememory_instance_2.VmSize \
    projectA:projecta_zopememory_instance_3.VmSize \
    projectA:projecta_zopememory_instance_4.VmSize
  total_memory.projectA.label project A

  total_memory.projectB.sum \
    projectB:projectb_zopememory_instance_1.VmSize \
    projectB:projectb_zopememory_instance_2.VmSize \
    projectB:projectb_zopememory_instance_3.VmSize \
    projectB:projectb_zopememory_instance_4.VmSize
  total_memory.projectB.label project B

  total_memory.projectC.sum \
    projectC:projectc_zopememory_instance_1.VmSize \
    projectC:projectc_zopememory_instance_2.VmSize \
    projectC:projectc_zopememory_instance_3.VmSize \
    projectC:projectc_zopememory_instance_4.VmSize
  total_memory.projectC.label project C

  total_memory.projectD.sum \
    projectD:projectd_zopememory_instance_1.VmSize \
    projectD:projectd_zopememory_instance_2.VmSize \
    projectD:projectd_zopememory_instance_3.VmSize \
    projectD:projectd_zopememory_instance_4.VmSize
  total_memory.projectD.label project D

  total_memory.projectE.sum \
    projectE:projecte_zopememory_instance_1.VmSize \
    projectE:projecte_zopememory_instance_2.VmSize \
    projectE:projecte_zopememory_instance_3.VmSize \
    projectE:projecte_zopememory_instance_4.VmSize
  total_memory.projectE.label project E

For more information please check:
http://munin-monitoring.org/wiki/aggregate_examples
http://munin-monitoring.org/wiki/PercentGraphHowto
http://munin-monitoring.org/wiki/stack_examples

Costruire su Amberjack

Abbiamo concepito e realizzato Amberjack, un sistema efficace e intimamente legato a Plone per generare tutorial sul CMS e su qualsiasi prodotto Plone, per consentire, a chi sviluppa nuovi prodotti Plone, di offrire il massimo supporto a coloro che useranno tali prodotti, aumentandone il gradimento e consentendo a tutti di utilizzarli al meglio. Questo livello di supporto si riverbera in positivo sull'intera comunità e sull' immagine pubblica di Plone.

Tuttavia, generare un tutorial Amberjack, fino a ieri, era un'attività piuttosto lenta, che richiedeva una certa dimestichezza con il linguaggio Python e con la programmazione a basso livello. Tali abilità non sono necessariamente presenti in chi, ad esempio negli Enti Pubblici, si occupa di formazione e comunque di supporto agli Utenti. Capita così che prodotti sviluppati all'interno degli Enti, con una partecipazione più o meno limitata delle Aziende, non abbiano ancora beneficiato di Amberjack.

Windmill e Amberjack, un matrimonio di interesse... per tutti!

Come potrete capire dal video che precede, per non inventare l'acqua calda, siamo ricorsi a Windmill (http://www.getwindmill.com/), prodotto libero ben noto a chi, come noi, pratica il test driven development. Windmill si basa su uno strumento installabile lato Client e integrato con Python, e su una serie di servizi Web  (acceduti via proxy tramite chiamate javascript remote) che centralizzano alcuni dei processi di generazione dei test, ad esempio il loro salvataggio su un file di idoneo formato.

E' così nato collective.amberjack.windmill, prodotto aggiuntivo che installa un'istanza Windmill sul sito Plone, e ne sostituisce alcune delle librerie con versioni specifiche per Amberjack. Ne nasce un "registratore di azioni" che, anzichè essere asservito alla creazione di casi di test, genera un tutorial esemplificativo, completo di ogni fase, dalla login alla logout. Ai formati nativi di Windmill, Python e Javascript, è stata aggiunta la possibilità di salvare queste registrazioni nel formato nativo di Amberjack, rendendo la loro creazione molto più rapida, semplice e immediata.

Prodotti Plone autoesplicativi

Il tutorial può, indifferentemente, essere creato su una istanza Plone locale o direttamente sul sito di produzione, passando l'URL come parametro sulla linea di comando al momento dell'avvio di Windmill. A prescindere dall'istanza Plone utilizzata per la generazione del tutorial, esso può agevolmente essere ricontestualizzato su un server differente grazie al supporto agli URL relativi. Il file zip generato da Windmill viene caricato sul sito di produzione tramite un'apposita funzionalità di upload.

A questo punto, non manca niente: Amberjack e Windmill, sposi felici, annunciano la nascita del loro pargolo, un Plone veramente autoesplicativo, che starà a tutti noi fare crescere nel modo migliore.

I already talked about the features of collective.navigationtoggle in previous post, but the new release helped me to be sure of one thing: the unobtrusive approach chosen was good.

The new version also add some refactoring and support for other themes than the classic Plone one. Plone 4 is coming... we must live with this and luckily the products migration has begun.

What is more difficult, after years the default theme is changed (for what I remember, the default theme you all know is with us from Plone 2.0... maybe some changes was done to it at Plone 2.1, but the core never changed). All products that act on Plone UI must check also the new Sunburst theme.

Going back to navigationtoggle, I choosed an approach that was "use existing Plone navigation element to know how to render new ones".

For the new release I only empowered some existings feature, like also generate CSS classes for new element on the navigation.

Why? In Plone 3 navigation main node is like this:

<li class="navTreeItem visualNoMarker">
      <div>
        <a title="..." class="state-... navTreeFolderish" href="...">
            <img width="16" height="16" alt="..." src="...">
            <span>Foo</span>
        </a>
    </div>
   ...
</li>

And Sunburst is like this:

<li class="navTreeItem visualNoMarker">
        <a title="" class="state-... navTreeFolderish contenttype-..." href="...">
            <img height="16" width="16" alt="Folder" src="...">
            <span>Foo</span>
        </a>
   ...
</li>

Apart some node difference (no more containing DIV) the new theme also rely on a contenttype-xxx class.

What is funny (and what make me say "thanks navigationtoggle") is an unwanted behavior of the current Sunburst theme. A bug that double the content type icon: one given from the IMG tag and another ones from CSS, thanks to the new class.

I'm not interested in this bug (Irene says that probably it has been already fixed), but using navigationtoggle with this bugged version of Sunburst... also make the bug applyed to elements navigation nodes generated by our script!

This (uncommonly) is good as respect the original idea: the original theme use doubled icons?! Is not a problem of navigationtoggle, so do it!

When Web pages load and run things

Let's start with CSS. Browsers load HTML source from the Web. Inside the page you will find resources that are CSS file. Immediately the resource is loaded and the rules inside are applied to your HTML.

Now switch to Javascript resources. For Javascript... it's the same. The Javascript code is executed as soon as it is found in the page...

...but for this reason, when we need to act using Javascript on an already loaded DOM, we rely onto Javascript events.

We read immediately the code, but the execution is postponed later, when the page is fully loaded.

As the use of jQuery became standard for those tasks (especially in Plone) we always use something like this:

jq(document).ready(function() {
    // do something
});

When this lead to problems

Although we have really no choice, there are some cases where this "postpone things" is not perfect: when we need to apply (using Javascript) CSS classes on page elements at page load time.

But we can't avoid making those actions when page is loaded.

If we don't rely on onload event, we have no ready DOM to traverse. So we can't load and change a DOM node if the page is not fully loaded (even if we put the Javascript script after the HTML that define the node).

<html>
<body>
    <div id="foo">Hello world</div>
    <script type="text/javascript">
    <!--
        var foo = document.getElementById("foo");
        alert(foo.innerHTML);
    // -->
    </script>
</body>
</html>

The code above is bad, even if you are using or not jQuery... So we really need to wait for the moment when DOM is ready. You can't act of the page DOM before it is fully loaded.

However: what is the problem applying CSS style when the DOM is loaded?

The nasty effect can be a visual flip.

The page in the browser show the DOM node with the original CSS style, then after some time (that can be not so brief sometimes if the page is full of elements and heavy scripts) the Javascript engine run your code, and the node is changed: your new CSS class or your new scripted style is applied.

<html>
<head>
    <style type="text/css">
    #foo {
        background-color: red;
    }
    </style>
    <script type="text/javascript">
    <!--
        window.onload = function() {
            ... MANY OTHER EXPENSIVE OPERATIONS
            var foo = document.getElementById("foo");
            alert(foo.innerHTML);
        }
    // -->
    </script>
</head>
<body>
    <div id="foo">Hello world</div>
    ... A LOT OF MANY AND MANY HTML NODES
    <script type="text/javscript">
    <!--
        var foo = document.getElementById("foo");
        alert(foo.innerHTML);
    // -->
    </script>
</body>
</html>

A practical example

A customer ask us to develop a Plone portlet that:

• show some random images when the page is load
  
• works behind a reverse proxy (Varnish)
• works with Javascript disabled (accessibility and graceful degradation)

Step 1

Varnish is caching all our resource, images and also HTML for every page. We can't (and don't want) change this.
How to cache everything but some little images inside a portlet?

The idea is to use Javascript  for performing AJAX request for this portlet and obtain a structure of data. The cache of this kind of request can be avoided easily.

Step 2

So we are able to load an HTML for the portlet without images then, when the DOM is ready, we can populate the portlet waiting for the AJAX call to the server. For some time the visitor see and empty portlet that magically begin load images. The effect is pleasant (at least... it's not annoying).

But we can't!
The portlet must work also with disabled Javascript... So we must load random images also when the page is loaded.

NB: if the visitor use a browser with Javascript disabled, we can only give him some random pre-loaded images, but we can't prevent Varnish cache of the whole page. Reloading the same page will show him the same images for some minutes. This is acceptable for us (and for the customer!).

Step 3

The final result is to load the first "static" images in the portlet itself, then use Javascript as described at step 1: changing those images with new ones obtained from AJAX call.

This lead to the ugly visual flip effect I talked above.

I can't explain why (this is not my work), but see an empty section that is filled after a little delay is not ugly... instead seeing a set of images that suddenly change to other is... bothersome!

Step 4?

Ok, so we can simply load static images hidden by some CSS class, then using Javascript we can show them only after the AJAX call and...
Opss!

But in this way we don't see any image when Javascript is disabled!

Ok... step 4 aborted.

Scripted CSS Injection

The perfect world is the one where the step 4 is performed, but only with Javascript enabled.

I need a CSS that is loaded early like all other CSS in the page (so its style is applied immediately to the page) but only when Javascript is enabled.

I found a way to do this, but surfing the web I was not able to find other example like this one. So I called this approach Scripted CSS Injection (SCI)... maybe someone can point me to other original name or example?

However... how this works? Simply generating the additional CSS... with Javascript!
For this we use the standard window.write Javascript API. The window.write command is used commonly to write HTML inside windows (is more common to use it in popup windows for generating the contained HTML from scratch).

The additional Javascript is load in the page head section and it doesn't wait for DOM load. The one in our product is only one line:

document.write('<style type="text/css">.hideFlag img {display: none}</style>');

As I said at the beginning, Javascript is interpreted as CSS, so immediately when found in the page.
The browser will add to HTML the style node immediatly.

What is nice of SCI approach is obvious: a browser with no Javascript support can't add the CSS rule to the page!

Fairytale gone well

This technique finally lead us to a portlet that:

• will show cached images if without Javascript support, but images are still random (chosen server side and changed with some delay)
• will show random (and not cachable) images client side if Javascript is enabled
• No ugly visual flip effects. With Javascript enabled static images are loaded hidden, then new dynamic ones are taken from the server and show. Thanks to SCI approach.
  

For more info, check the code of auslfe.portlet.multimedia.

rt.vuvuzela is available from pypi

As usual add rt.vuvuzela to eggs and zcml into the [instance] section of your buildout.

Then you can just go to your site and you will have a nice vuvuzela view displaying a player stealed borrowed from wikipedia. Here you can see a snapshot of the view:

To see it live just append "vuvuzela" to your browser url, e.g.:

http://nohost.com/vuvuzela
http://nohost.com/mycontent/vuvuzela

rt.vuvuzela logo???

C'è ancora chi crede che un sito Plone si riconosca a prima vista: può essere, se parliamo di installazioni "out of the box" o comunque se si decide di restare nelle skin più classiche. Ma certamente non è un principio generale: la flessibilità di Plone è testimoniata non tanto dalla possibilità di impostazioni grafiche complesse e innovative, quanto dalla sua possibilità di mimetizzarsi completamente in un layout grafico preesistente.

Due casi di studio, entrambi provenienti dall'ambito della Regione Emilia Romagna, dimostrano questa flessibilità con particolare evidenza:

• Nel sito "Io Partecipo" / "Uno x uno", che propone una soluzione mista Plone / non Plone, l'integrazione trasparente di Plone è stata ottenuta grazie a Deliverance (diversi dei nostri tecnici hanno parlato di questa soluzione nelle loro presentazioni: Massimo, Stefano, e nel nostro blog). Deliverance consente di ridistribuire gli elementi grafici di uno o più layout esistenti, assemblandoli in modo differente e - se necessario - armonizzandoli dal punto di vista grafico. Nel caso di "Io partecipo", tutti gli elementi del layout grafico sono riproposti direttamente da un preesistente sito, salvo la colonna di sinistra (notizie, commenti, argomenti) che è invece tratta da un sito plone ad hoc. Ciò ha consentito di mantenere inalterata l'originaria infrastruttura, pur offrendo ai redattori i vantaggi di Plone per la redazione delle informazioni modificate più di frequente.
• Invece, nel caso di Ermes, il portale della Regione Emilia Romagna, gli utenti non si sono accorti di nulla nonostante l'intero portale sia stato interamente reingegnerizzato in Plone. In questo caso, Plone è stato meticolosamente personalizzato in modo molto granulare, per caratterizzare ogni elemento visibile secondo i tematismi grafici e la struttura del portale originale: la buona riuscita dell'operazione può essere testimoniata da chiunque abbia usato Ermes negli ultimi mesi - a parte la differente struttura degli URL, nulla denuncia il cambiamento di tecnologia. Altrettanto rimarchevole il fatto che, sebbene l'originale implementazione fosse in HTML statico e quindi particolarmente leggera, i tempi di caricamento delle pagine in Plone sono immutati: insomma, l'enorme vantaggio di una gestione dei contenuti immediata e "through the web" non si paga in termini di prestazioni. Tra l'altro, a differenza della precedente implementazione statica, il portale Plone sarà agevolmente adattabile ad altri media palmari (ipad/iphone/smartphone in genere).
  

In conclusione, le ragioni per non rinunciare alla veste grafica "storica" di un portale sono molteplici, soprattutto legati all'elevato numero di utenti abituali, e bisogna trasformare questa esigenza in un'opportunità. Il fatto che Plone lo consenta è importante per molti validi motivi:

• dimostra la flessibilità della tecnologia
• abbatte un ostacolo spesso insormontabile: la paura del cambiamento; L'alibi "Ma i nostri utenti sono abituati a vedere le cose in questo modo!" si dissolve con un "E così continueranno a vederle!";
• preserva gli investimenti passati: se il progetto di comunicazione su cui è disegnato il portale è valido, può avere senso mantenerlo anche al variare della tecnologia.

Prima di tutto: usi ZopeSkel... vero?

La frase "non uso ZopeSkel perché sono abituato a fare le cose a mano" non è una scusa valida!

Personalmente uso ZopeSkel solo per la creazione iniziale dell'egg, poi non mi addentro mai molto nell'uso dei "paster subcommands" (ma non sempre... creare nuovi contenuti per Archetype è comodissimo), ma quello è sufficiente. Usare ZopeSkel per generare lo scheletro dei propri egg significa seguire la convenzione e lo standard!

Non mi addentro ulteriormente sull'argomento... se non usi ZopeSkel e sei incuriosito puoi leggere l'ottimo articolo che trovi su plone.it.

Le novità nascoste

Prima di tutto verifica di avere disponibile l'ultima versione (al tempo in cui scrivo siamo alla 2.17):

keul@redturtle:~$ sudo easy_install -U ZopeSkel

Notate innanzi tutto che il vostro sistema ha ora disponibile un secondo comando oltre al già conosciuto paster (hai letto l'articolo sopra, vero?). Il nuovo script è zopeskel.

Cosa fa? A cosa serve? E' principalmente una forma semplificata del primo script... diciamo un "paster for dummies", ma la vera comodità e fulcro di questo articolo è la possibilità di creare tramite lo script zopeskel un file di configurazione con alcune preferenze di default.
Possiamo finalmente usare paster e premere molte più volte "invio" (accettando la risposta predefinita) di quanto non venisse fatto fin'ora.

Lanciando la guida di zopeskel otteniamo questo:

keul@redturtle:~$ zopeskel --help
...
You can generate a starter .zopeskel file by running this script with
the --make-config-file option. This output can be redirected into
your ``.zopeskel`` file::

    bin/zopeskel --make-config-file > /path/to/home/.zopeskel
...

In pratica, nella nostra home possiamo ospitare un file con nome ".zopeskel" con alcune configurazioni predefinite e zopeskel stesso ci permette di generarne uno di esempio, con una sintassi valida, da personalizzare poi.

keul@redturtle:~$ zopeskel --make-config-file > ~/.zopeskel

Le opzioni non sono poche e forse un tantino esagerate. Potreste ad esempio avere configurazioni diverse a seconda del tipo di comando paster che state usando...
Io rimango per un uso semplice!

# This file can contain preferences for zopeskel.
# To do so, uncomment the lines that look like:
#    variable_name = Default Value

[DEFAULT]

expert_mode = all
version = 0.1.0
author = RedTurtle Technology
author_email = sviluppoplone@redturtle.net

[archetype]

# Expert Mode? (What question mode would you like? (easy/expert/all)?)
# expert_mode = easy
...

La sezione [DEFAULT] sarebbe solitamente vuota ma avete esempi completi in tutte le altre sezioni (una per ogni tipo di template paster disponibile) anche se tutte commentate.

Se come me volete configurare solo la sezione [DEFAULT], usate qualche copia incolla!

Quella postata qui sopra è esattamente la mia configurazione, che vado ad analizzare.

• expert_mode. E' un'opzione piuttosto nuova e il default sarebbe "easy"; è interessante perché permette di porre all'utente "meno domande"... ma visto che fingo di essere uno smanettone, preferisco che mi venga chiesto "tutto".
  Scherzi a parte, alcune delle domande che vengono saltate le trovavo invece importanti.
• version. La versione del prodotto. Il default è 1.0, ma personalmente preferisco 0.1.0, ben considerando che paster viene usato alla creazione... è molto probabile che la prima release del vostro super prodotto non sia tanto super... e che sia di qualità alpha o beta.
• author. Nel mio sistema, a lavoro, è normale che il codice sviluppato sia della mia Azienda. Niente più scrittura a mano del nome dell'Azienda e niente più differenze tra me e il mio collega.
• email. Di nuovo convenzione (un unico indirizzo aziendale per lo sviluppo plone)... ma potrei specificare la mia email personale!

Teniamo comunque presente che questi valori sono solo i default. La gestione dell'eccezione è sempre possibile (non diventate troppo pigri ... potete sempre cancellare la risposta che paster sta proponendo e scrivere da capo... come poi avrete fatto fin'ora!).

Un file .zopeskel in ogni azienda

Perché no? Pensare che ogni sistema per sviluppatori all'interno di un'azienda abbia questa configurazione porta uniformità al rilascio di codice alla comunità. Non sto ovviamente parlando delle prime opzioni che abbiamo illustrato, che sono più che altro preferenze davvero personali.

Potrebbe non essere il vostro caso, magari la Vostra Azienda preferisce mantenere come autore lo sviluppatore stesso (oppure mettere sempre come autore il nome del capo programmatore che vive sulle vostre spalle e che vi ruba la fama). Altre magari vorranno che tutto il codice risulti fatto dall'Azienda, ma potrebbe voler mantenere la Vostra e-mail (così che siate voi ad essere disturbati in caso di problemi).

Questo, come dicevo è come il mio sistema è configurato qui in RedTurtle... a casa mia ho un PC che ogni tanto uso per i miei personali progetti Plone. Ovviamente anche là uso paster ma in una configurazione diversa!

Provate anche voi. E' comodo...