This is done instead of putting multiple entries in a single field,  but the problem comes from the fact that the notes mail document includes a 'Received' field for every server it has passed. 

Lotus Notes give us a documented method that gets the text values of the Received items in a mail document.

stringArray = notesDocument.GetReceivedItemText( )

But sometimes it doesn't work...

Agent message: Received Item is not standard format - access with GetItemValue

Thanks to Raymond Neeves for his great function

After calling this, you can simply access all values of Received field with

Forall v In doc.Received
    msgbox v
End Forall

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

Every time I make the same stupid error! So, let's make quickly, a guide for obtaining this behavior.

The trim() function works only on Firefox and maybe other browsers, but not on IE.

In my experience the stript() function instead works better, both on Firefox and IE.

So what is the problem? That every time I forget to use this last one, and I use again trim instead of stript...

There is a solution for my lazy brain? Well... I use very often (AKA "always") jQuery for our projects, so... please Luca... from now just use jQuery.trim().

I feel better! No more error from now...

...

... until next time.