Tuffarsi in Archetypes

Un intero gruppo di grandi esempi è disponibile per Archetypes, così piuttosto che costruirne uno per il libro, mostriamo ArchExample, che viene fornito con l'installazione di Archetypes. Questo aggiunge un tipo di contenuto chiamato article che fornisce un esempio grezzo della potenza di Archetypes.

Article.py contiene il codice del prodotto principale. Vedete che il codice sembra piuttosto diverso dagli esempi precedenti. Contiene schema

StringField("blurb",
            searchable = 1,
            widget = TextAreaWidget(),
            ),

Questo pezzo di codice denota che avete un attributo sul tipo di contenuto chiamato fascetta (blurb), che è una stringa, e verrà mostrata come una text area HTML. Discuto tutte le opzioni per campi e widgets in un momento. Per ora, diamo un sguardo al tipo di contenuto Plone. In figura 13-1, abbiamo aggiunto tipo di contenuto blurb.

Figura 13-1. La parte di blurb del tipo di contenuto

Con solo queste quattro linee di codice, avete aggiunto un campo al vostro tipo di contenuto. Gli elementi del modulo standard che si aspetterebbe Plone sono presenti; se modificate qualche cosa e ritornate in un secondo tempo, il vecchio valore è mostrato, gli errori sono tattati con eleganza, e così via. Come dimostrazione di come sia facile modificare, cambiate l'etichetta nel modulo per visualizzarlo come Article Blurb, e cambiate il campo per essere richiesto. Per fare questo, fate le seguenti modifiche:

StringField("blurb",
            required = 1,
            searchable = 1,
            widget = TextAreaWidget(label="Article Blurb"
            ),

Qui avete aggiunto il parametro required = 1 che rende questo campo obbligatorio, ed un parametro all’etichetta. Se riavviate Plone ed aggiunge un nuovo article, l'interfaccia utente è ora cambiata per riflettere il nuovo schema. Il campo è ora chiamato Artiche Blurb.

Figura 13-2. La parte del tipo di contenuto di Article Blurb

Questo non è solamente un cambio estetico; il cambio riflette la modifica dello schema fondamentale, e questa è la vera potenza di Archetypes. Solamente comparando questo con lo scrivere prodotti in Python, potete vedere che tutto il lavoro faticoso dallo scrivere un prodotto è stato rimosso. È come questo: se si può definire un schema, poter mettere insieme completamente un archetipo è assolutamente immediato. Una volta che avete fatto, potete modificarlo facilmente e potete vedere le modifiche prendere effetto.

Se fate qualsiasi di queste modifiche per provare gli esempi seguenti, dovrete riavviare Plone. Solamente allora tutti i nuovi cambiamenti saranno caricati e propriamente registrate. Per ulteriori informazioni su questo, vedete successivamente la sezione "Sviluppare con Archetypes" in questo capitolo.

Spiegare Schema, Campi e Widgets

La definizione fornita dal dizionario di Merriam-Webster di schema è la seguente:

schema:

Nel linguaggio Archetypes, un schema

<manca qualcosa - Ugo >

Ogni campo ha un widget definito. Un widget

Figura 13-3 Mostra la relazione tra schema, campi, e widgets.

Figura 13-3. La relazione tra schema, campi, e widgets

Schema((
    StringField('group',
        vocabulary=ARTICLE_GROUPS,
        widget=SelectionWidget(),
        ),
        # other fields here
        )

schema = BaseSchema +  Schema((
    StringField('group',
                vocabulary=ARTICLE_GROUPS,
                widget=SelectionWidget(),
                ),
    ...

from Products.Archetypes.public import BooleanField

from Products.Archetypes.public import IntegerField
# a simple field for age
age = IntegerField('age')

from Products.Archetypes.public import BooleanWidget

from Products.Archetypes.public import IntegerField
from Products.Archetypes.public import IntegerWidget
# a simple field for age
age = IntegerField('age',
       widget=IntegerWidget(label="Your age")
       )

bankAccountNumber = StringField('bank',
   widget=StringWidget(
           label="Bank account number",
           size=20)
         )

Alcuni esempi di combinazione di campi e di widget

Questa sezione contiene alcune combinazioni utili che sembrano essere usate comunemente e che potete trovare utili come esempi. Per questo esempio, creiamo un casella a discesa della vostra frutta preferita. Definiremo l'attributo vocabulary come un lista di stringhe. Ognuno dei valori della lista è una stringa del tipo fruit; per cui, il tipo di campo è un StringField. Poiché stiamo definendo il widget come un SelectionWidget, si presenterà come un casella a discesa, così come:

StringField('fruit'
    vocabulary = ["Apple", "Orange", "Mano", "Banana"],
    widget = SelectionWidget(label = "Favourite Fruit")
    )

La ImageField è utile per creare e mantenere immagini in un sito Plone. Per avere un bel semplice campo dove gli utenti possono caricare [upload] immagini, usiamo il seguente:

ImageField('portrait',
    widget = ImageWidget(label = "My picture"),
    )

Il tipo seguente è un tipo veramente complicato di contenuto. La maggior parte dei contenuti digitati possiedono un campo principale che può ricevere dati. Se pensate al tipo di documento di base, osserverete un campo corpo (body) ove digitate e modificate. Questo unico campo body è il testo principale del tipo di contenuto. Quindi per questo campo standard, avete solamente alcuni attributi che dovranno essere aggiunti.

Per primo, desiderate che questo campo sia ricercabile, così dovete impostare l'attributo searchable. Successivamente, vorrete che questo campo risponda alle richieste FTP e WebDAV, così dovete impostare l'attributo primary (potete trovare ulteriori informazioni su questo nel sidebar "Il campo primary: Ordinare e Rispondere a FTP e WebDAV"). Desiderate che siano caricati [upload] molteplici tipi di contenuto, così, per questa ragione, settate * allowable_content_types*. Avete bisogno di sapere chiaramente, poi, come visualizzare il campo, così, per questo ponete * default_output_type*. Tutto questo allora fornisce il campo seguente:

TextField('body'
          searchable = 1,
          primary = 1,
          default_output_types = 'text/html',
          allowable_content_types = ('text/plain',
                                     'text/structured',
                                     'text/restructured',
                                     'text/html'),
          widget = RichWidget(label = 'Body'),
          )

Sovrascrivere [Overrindig] Viste ed Actions nella classe Base

Archetypes crea viste predefinite ed azioni basate su un set standard di requisiti che vanno bene per molte necessità. Le azioni sono vedere, modificare, e le proprietà, chiaramente; i riferimenti sono un'altra azione che guarderà a lui un momento. Non trovete i modelli di pagina dell’oggetto per vista od edita; questi sono generati automaticamente da Archetypes. Comunque, potete modificarli.

Ci aspettiamo che in molti casi vorrete avere la priorità sul metodo vista e di offrirne uno proprio vostro; Di default è base e non è mirata all’inizio una pagina perfetta (chiaramente, essendo una pagina Plone, è migliore del vostro sistema di gestione dei contenuti medio). Comunque, potete avere specifiche necessità che fanno riferimento al contenuto; forse è una questione di presentare il vostro contenuto in un certo modo.

Archetypes di fatto crea una classe per ogni tipo di contenuto. Molto nello stesso modo in cui avete creato una classe per il tipo di codice sorgente nel capitolo precedente, potete creare una classe base per il vostro archetipo. Questa classe base è stata chiamata BaseContent ed è disponibile nel modulo public di Archetypes per l’importazione. Questa classe BaseContent definisce ogni cosa di cui Archetypes ha bisogno di conoscere. Realizzando questa classe vi viene offerta un'opportunità di avere la priorità pressocché su qualsiasi cosa che desiderate nella classe.

Come ora mostriamo, ci sono due parti per questo. Prima, create un'azione che verrà usata dalle informazioni di tipo di fabbrica [factory]; in Archetypes fate questo assegnando l’attributo action della classe. Per esempio:

from Products.Archetypes.public import BaseContent
 
class Article(BaseContent):
    # other stuff
    actions = ({ 'id': 'view',
                 'name': 'View',
                 'action': 'string:${object_url}/article_view',
                 'permissions': (CMFCorePermissions.View,)
                },)

Secondo, avete bisogno di creare un modello di pagina, chiamato article_view, per la vista attuale dell'oggetto. Questa stringa definisce un modello di pagina che il tipo di contenuto localizzerà nello skin per questo prodotto. In questo caso, troverà il modello di pagina corrispondente nel File System nella directory dello skin/archexample di ArchExample. Potete trovare anche una copia di questo modello di pagina nell’Appendice B. Questo può essere un semplice o un complicato un modello di pagina come desiderate.

Per prendere efficacia, dovete ravviave Plone per le modifiche. In questo caso, state modificando un'azione installata all’interno del tool portal_types allorquando il prodotto è stato installata. Per questa ragione, se cambiamente questa azione, avrete bisogno di reinstallare il prodotto. Per fare questo nell'interfaccia Plone, cliccate Plone setup.

Tutti gli elementi nel tipo d’informazione di factory possono essere soprascritte [overriden] creando un attributo di quel nome sull'oggetto. Per sovrascrivere content_icon create un attributo chiamato content_item. Per esempio:

class SomeProduct(BaseContent):
          """ Some product """
          content_icon = "some_icon.gif"

Sovrascrivere i metodi di Default

Nella Tabella 13-2, abbiamo menzionato la possibilità di sovrascrivere alcuni metodi di default che occorrono sui tipi di contenuto, come accessor e mutator. Questa è un opzione avanzata che permette la manipolazione dei campi al momento della modifica (da rivedere).

Giusto come il progetto open source dell'ultimo capitolo, potete accedere a questi attributi od a questi campi usando i mediti accessors e mutator. Alcuni metodi default sono disponibili. Se il vostro nome del campo è blurb, allora questi metodi saranno getBlurb e setBlurb. Il termine get <manca qualcosa – Ugo >

Comunque, potete volere fare qualche cosa di diverso in accessor o mutator. Supponete di voller filtrare il valore di un campo, come correggere sempre l’ortografia del nome della vostra società o cambiare il valore di alcune altri campi quando un certo compo viene modifica. Allora potete fare così avendo la possibilità di sovrascrivere i metodi predefiniti. Nell'esempio seguente, realizzerete un nuovo metodo chiamato getSpecialBlurb che prende il blurb che qualcuno ha digitato e lo manipolerete prima di ritornarlo al client. In questo caso, state sostituendo il testo Perl

getSpecialBlurb Article

class Article(BaseContent):
 
    def getSpecialBlurb(self):
        """ The view for an article """
        blurb = self.getField('blurb').get(self)
        blurb = blurb.replace('Perl', 'Python')
        return blurb

Avrete bisogno di modificare anche il vostro campo così che usi questo metodo:

StringField('blurb',
    searchable=1,
    widget=TextAreaWidget(),
    accessor="getSpecialBlurb",
),

In questo esempio, in qualsiasi momento che il campo blurb ha accesso, per esempio, ad una pagina di vista o di modifica viene restituito il valore di getSpecialBlurb. Archetypes conosce l’accesso al metodo poiché il nome del metodo è definito come un valore stringa passato al parametro accessor. C'è un bit di frode voluta – per accedere al valore crudo dell'attributo, avete bisogno di trovare il campo e poi invocare il metodo get. Questo è una linea piuttosto confusa blurb=self.getField ('blurb'). get(self). Il pattern getting il campo e quindi (ri)chiamare un metodo su lui è davvero piuttosto comune in Archetypes [da rivedere… ndt].

L'esito pratico di questo ora è che, non vi è nessuna questione quando o come una persona digiti la parola Perl

Mettere insieme il resto del tipo di contenuto

Ora abbiamo trattato tutti gli elementi principali del tipo di contenuto. Il listato 13-1 mostra tutto insieme il codice. Noterete che il resto del codice è più compatto del prodotto Python perché Archetypes lavora così molto per voi.

Listato 13-1. Article.py

from Products.ArchExample.config import ARTICLE_GROUPS
from Products.Archetypes.public import BaseSchema, Schema
from Products.Archetypes.public import StringField, TextField
from Products.Archetypes.public import SelectionWidget, TextAreaWidget
from Products.Archetypes.public import RichWidget
from Products.Archetypes.public import BaseContent, registerType
from Products.Archetypes.Marshall import PrimaryFieldMarshaller
from Products.CMFCore import CMFCorePermissions
from config import PROJECTNAME
 
schema = BaseSchema +  Schema((
    StringField('group',
                vocabulary=ARTICLE_GROUPS,
                widget=SelectionWidget(),
                ),
    StringField('blurb',
                searchable=1,
                widget=TextAreaWidget(),
                ),
    TextField('body',
              searchable=1,
              required=1,
              primary=1,
              default_output_type='text/html',
              allowable_content_types=('text/plain',
                                       'text/structured',
                                       'text/restructured',
                                       'text/html',
                                       'application/msword'),
              widget=RichWidget(label='Body'),
              ),
           ),
     marshall=PrimaryFieldMarshaller(),
     )
 
class Article(BaseContent):
    """This is a sample article; it has an overridden view for show,
    but this is purely optional
    """
 
    schema = schema
 
    actions = ({
        'id': 'view',
        'name': 'View',
        'action': 'string:${object_url}/article_view',
        'permissions': (CMFCorePermissions.View,)
        },)
 
registerType(Article, PROJECTNAME)

A parte un gruppo di importazioni in alto e lo schema, abbiamo trattato tutti i contenuti di questo codice, con un'eccezione: registerType. Questa funzione registra il vostro oggetto con il prodotto. Ciascun prodotto può avere moltiplici tipi di contenuto, così questa funzione prende l'oggetto ed il nome del progetto. In questo caso, il nome del progetto è importato dal file di configurazione, come visto precedentemente. Il file di configurazione, config.py contiene variabili similari per la configurazione del prodotto, come mostrato nel listato 13-2.

Listato 13-2. Il file di configurazione di ArchExample

from Products.CMFCore.CMFCorePermissions import AddPortalContent
from Products.Archetypes.public import DisplayList
 
ADD_CONTENT_PERMISSION = AddPortalContent
PROJECTNAME = "ArchExample"
SKINS_DIR = 'skins'
 
GLOBALS = globals()
 
ARTICLE_GROUPS = DisplayList((
    ('headline', 'Headline'),
    ('bulletin', 'Special Bulletin'),
    ('column', 'Weekly Column'),
    ('editorial', 'Editorial'),
    ('release', 'Press Release'),
    ))

La variabile ARTICLE_GROUPS è un tuple di un tuple di stringhe per usarla nel group widget. Potrete usare solo una semplice tuple di stringhe, ma in questo caso l'esempio sta usando la classe DisplayList che è un'occassione di mostrare un diverso valore all'utente da quello che sarà messo nel modulo. In questo caso, lo HTML per ArticleGroups è visualizzato in un elemento HTML scelto, come così:

<option value="headline">Headline</option>
<option value="bulletin">Special Bulletin</option>
...

Un altra intuizione insolita è l'uso della funzione globals - che è una funzione nativa [built-in] di Python, che contiene tutti i simboli globali. Questo calcola il path della directory dello skin nel File System così che possiate costruire una vista delle directory del File System dello skin per il tool skin. La funzione di inizializzazione del prodotto, __init__.py è anche molto più semplice. Con una nuova inclusione, il processo e la lista delle funzioni tipo sembrano questi:

from Products.Archetypes.public import process_types, listTypes
content_types, constructors, ftis = process_types(
    listTypes(PROJECTNAME),
    PROJECTNAME)

La funzione listTypes è un'utilità di Archetypes che restituirà tutti i tipi che prima avete registrato. Questi quindi verranno passati alla funzione process_types che a turno ritorna tutti i tipi di contenuto, i costruttori, e gli oggetti tipo factory information. Questi sono tutti gli stessi items che avete registrato nel prodotto Python; è solo che questa funzione di utilità rende tutto un pò più facile.

Finalmente, avete la funzione di installazione nel Extensions install.py. Questo script è ora imbarazzantemente piccolo perché di tutto il lavoro che avete fatto prima si sono occupati due funzioni di utilità, installTypes ed install_subskin. Il termine subskin <manca qualcosa – Ugo >

Listato 13-3. Script d'installazione

from Products.Archetypes.public import listTypes
from Products.Archetypes.Extensions.utils import installTypes,
install_subskin
from Products.ArchExample.config import  PROJECTNAME, GLOBALS
 
from StringIO import StringIO
 
def install(self):
    out = StringIO()
    installTypes(self, out, listTypes(PROJECTNAME), PROJECTNAME)
    install_subskin(self, out, GLOBALS)
    out.write("Successfully installed %s." % PROJECTNAME)
    return out.getvalue()

La versione completa di ArchExample è disponibile nel sito web del Plone Book presso http://Plone-book.agmweb.ca, e dovreste essere capace di lasciar cadere questo e di eseguirlo sul vostro sito. Come avete visto, questo tipo di contenuto è rapido e facile da sviluppare ed è facile da modificare, senza dovere scrivere molto codice.

Usare Id unici

Il concetto di Id unico è semplice ma è qualche cosa che è stato perso in Zope. Originalmente gli sviluppatori di Zope hanno presupposto di utilizzare il percorso ad un oggetto; sfortunatamente, questo ha mostrato di essere inadeguato. Come semplice esempio, si consideri quello che succede quando qualcuno cambia l'ubicazione di un documento – il vostro unico riferimento a quel documento è stato perso. Un Id unico è un tool veramente utile da avere. Archetypes crea un Id unico su ogni oggetto creato e lo salva nell'oggetto. Lo salva anche in un catalogo separato chiamato uid_catalog.

Potete vedere uid_catalog nella ZMI, ed è come l'oggetto di portal_catalog eccetto che ommette un piccolo pezzo di extra Application Programming Interface (API) avvolto e tutti gli indici che il primo contiene. È abbastanza semplice ora da ottenere un oggetto passando attraverso questo catalogo. Tutto ciò che dovete fare è ricercare nel catalogo il vostro oggetto. Per esempio, il seguente oggetto script (Python) può tirare qualsiasi l'oggetto registrato, se conoscete il relativo UID:

##paramaters=objectId
results = context.uid_catalog(UID=objectId)
return results[0].getObject()

Ma dove è realmente utile è nei riferimenti fra oggetti esistenti. Dite che cercate di riferirvi ad una o più immagini separate con vostro articolo. Queste immagini possono essere immagini caricate da altri utenti da un'altra data, forse parte di un database di immagine. Se queste immagini sono oggetti di Archetypes, allora potrete aggiungere un campo al vostro schema dell'articolo che leggete come segue:

ReferenceField("images"
    allowed_types=("Archetype Images",),
    multivalued=1,
    ),

L'utente ora troverà una casella a discesa di tutti gli oggetti Image di Archetype e sarate capaci di sceglierli. Dietro alle quinte state facendo riferimento all'UID di quel oggetto attraverso il catalogo. Troverete un esempio eccellente sui riferimenti in un prodotto chiamato ACME nel repository CVS di Archetypes presso http://sf.net/projects/archetypes.

Modificare i Widgets

Una domanda comunemente richiesta è, perché questi widget fanno questo? Un altro è, perché questi widget appaiano come questo? Spesso la risposta è qualche cosa come, perché ora – non andate a scrivere proprio i vostri. Siccome i widgets sono quelli che il client vede, questi requisiti sono client orientati. Tutti i widgets sono rappresentati come macro modello di pagina nel File System. Quindi è abbastanza semplice modificare i widgets o farne proprio i vostri. Se cliccate portal_skin

portal_skins Davvero, il termine macro < manca qualcosa qui – Ugo >

La macro view è visualizzata sulla pagina view ed è a sola lettura, di facile uso dall'articolo. La macro edit è quella mostrata sulla pagina di edit, ed è la macro ove un utente edita i dati. La macro di ricerca è chiamata quando state assemblando pagine di ricerca per il codice; qualche volta guardate proprio la macro edit, anche se può non essere. Un campo stringa può essere modificato come un campo stringa e può essere visualizzata come una stringa, ma è ricercabile usando una casella a discesa per selezionare tutte le opzioni disponibile.

Quindi, nel prodotto di esempio, assumiamo che avete un campo stringa che è l'indirizzo e-mail di una persona, e che volete mostrare che questo sia un collegamento e-mail cliccabile. Per questo creerete una nuova macro. In questo caso, non avete bisogno in realtà di sovrascrivere la macro di edit o di search – dopo tutto è giusto una stringa. Quindi, fate un nuovo modello di pagina chiamato email_widget.pt, come segue, che metterà nello skin del vostro prodotto:

<html xmlns:tal="http://xml.zope.org/namespaces/tal"
      xmlns:metal="http://xml.zope.org/namespaces/metal"
      i18n:domain="plone">
 
  <body>
    <div metal:define-macro="edit">
      <div metal:use-macro="here/widgets/string/macros/edit" />
    </div>
 
    <div metal:define-macro="search">
      <div metal:use-macro="here/widgets/string/macros/search" />
    </div>

Per la vista, avete bisogno di realizzare la stringa mostrata come un collegamento malto che è solamente la semplice rettifica seguente:

    <div class="field" metal:define-macro="view">
        <a href="#" tal:attributes="href string:mailto:${accessor}"
          tal:content="accessor">email</a>
 
    </div>
</body>
</html>

Ora che avete definito un modello di pagina che contiene il vostro codice, potete semplicemente far riferimento al nome del template come la macro nel vostro widget. Nel codice seguente, definite il campo posta elettronica ed un StringWidget come normale. Cambiate poi la vostra macro per usare la vostra bella nuova macro email_template, come così:

StringField('email',
    validators = ('isEmail',),
    widget = StringWidget(
        label='Email',
        macro='email_template'
    )
)

A questo punto state proprio cambiando la macro di un widget esistente. Fare un widget completamente nuovo è solo questione di definire un nuovo widget e quindi registrarlo. Tutti i widgets condividono la stessa classe base. Il seguente è un nuovo modulo chiamato EmailWidget.py che è collocato nella directory ArchExample. Create un nuovo widget e quindi registratelo all’interno del registro. Notate che la proprietà macro del widget (evidenziata) sia settato al valore del template:

from Products.Archetypes.Widget import TypesWidget
from Products.Archetypes.Registry import registerWidget
 
class EmailWidget(TypesWidget):
    _properties = TypesWidget._properties.copy()
    _properties.update({
       'macro' : "email_template",
       'size' : '30',
       'maxlength' : '255',
       })
 
registerWidget(EmailWidget,
    title='String',
    description='Renders a clickable email field',
    used_for=('Products.Archetypes.Field.StringField',)
)

Per includere questo nel vostro articolo, ora potete importare direttamente EmailWidget e potete usarlo senza dovere definire esplicitamente la macro, così come:

from EmailWidget import EmailWidget
 
StringField('email',
    validators = ('isEmail',),
    widget = EmailWidget(
        label='Email',
    )
)

Sviluppare oggetti Folderish

Avete già lavorato molto con gli oggetti folderish in Plone, ma potevate non saperlo. Un oggetto folderish possiede caratteristiche simili ad una cartella od ad una directory, vale a dire che può contenere separati oggetti individuali. Non v’è realmente nulla di speciale in un oggetto folderish - giusto eredita da una certa classe base per offrire le sue proprietà, e nuovi contenuti possono essere aggiunti.

Gli oggetti di Folderish sono utili molte ragioni per costruire. Loro offrono un semplice modo di creare raccolte di oggetti disparati in un'ubicazione. Loro inoltre permettono agli utenti di amministrarere i contenuti usando l’interfaccia utente standard di Plone, senza dover fare niente altro. Generalmente, è [abitudine -ndt] migliore tenere la cartella piuttosto semplice, e la logica dovrebbe essere nei vostro oggetti e nei workflow degli oggetti. Comunque, sempre delle eccezioni a ciò esistono ed un esempio classico è la famiglia dei raccoglitori, CMFCollector e PloneCollector entrambi dei quali sono del tutto oggetti complicati raccoglitori che offrono logica per un gruppo di problemi dei raccoglitore.

Di nuovo, il modo più facile per creare un oggetto folderish è usare Archetypes. Avete visto che c'èra un tipo BaseContent che per maneggiare tutto il lavoro ha avuto bisogno di creare un oggetto nonfolderish. Bene, c'è anche un tipo di contenuto BaseFolder che contiene ogni cosa [necessaria – ndt] per creare una cartella. Più avanti, troverà un schema speciale per le cartelle, da quando folderish obiettano anche di default abbia una descrizione. Fare un folderish dattilografare, solo assicura che cambiamentia le Sue classi vili ed i Vostroi schemi. Per esempio, la più semplice cartella possibilmente è il seguente:

from Products.Archetypes.public import BaseFolder, BaseFolderSchema
 
schema = BaseFolderSchema
 
class SimpleFolder(BaseFolder):
    """A simple folderish archetype"""
    schema = schema
 
registerType(SimpleFolder)

If you're going to store a huge amount of content in a folder, then a folder tends to become inefficient at about 100 objects. That's a rather arbitrary figure that should be taken with a pinch of salt; normal folderish objects are designed to be fast for small numbers of object. If you wanted, you could use a binary tree folder, which stores the objects internally in a more efficient binary tree, rather than a Python dictionary. To use this, just import BaseBTreeFolder and BaseBTreeFolderSchema and use these in your object instead. As far as developing a product is concerned, they work just the same, but unless you put a lot of data into them, you wouldn't likely notice any difference. I've stored more than 100,000 objects in BTreeFolder, and it's always responded well.

Maneggiare contenuto Microsoft Office

Maneggiare contenuto Microsoft Office, come documenti Word e Excell, è una sventura che tutti i sistemi di gestione di contenuto affrontano ad un certo punto. Comunque, questo in realtà è il caso per qualsiasi tipo di contenuto – Microsoft Office, OpenOffice.org, Portable Document Format (PDF), immagini, e così via. Usare queste forme di contenuto sui siti Web di solito causa alcuni problemi; questo è conosciuto bene, chiaramente. Modificare è poco pratico perché cliccando un documento si causa il suo download od, anche peggio, l'apertura nel vostro browser. Quando avete finito, dovete (ri)caricarlo di nuovo sul sito Web che normalmente può voler dire cliccandolo un po' di riaverlo.

Quando il contenuto è on-line, i contenuti non sono ricercabili perché non sono in formato semplice-testo [che – ndt] il catalogo potete capire. Ulteriormente, non potete vedere il contenuto on-line perché di nuovo non è in un formato Web-amichevole.

Avete un paio di soluzioni per risolvere il primo problema di modificare il contenuto. Se di nuovo presumete che la maggior parte dei vostri utenti stia usando Windows, allora usare WebDAV può essere ingannevole in quanto la realizzazione della cartella Web di Microsoft è di qualità discutibile. Invece, External Editor adempie del tutto bene a questa funzione – se Plone può dire ad External Editor che questo è un file Word, lo aprirà in Word.

Come per il resto, bene, Archetypes ha un pacchetto di trasformazione incorporato, chiamato Portal Trasforms, questo si occupa della trasformazione dei tipi di contenuto. Questo può prendere un file in un certo formato e può trasformarlo in HTML che sarà poi catalogato e lo HTML verrà visualizzato all’utente nell'interfaccia utente. Fa questo usando un processo di trasformazione esterno per trasformare i dati e leggere i risultati. Per esempio, se state usando Windows (sul server), poi Portal Trasforms prenderà il documento di Word caricato ed avvierà un oggetto Component Object Model (COM) che lo trasforma.

Tutto questo succede dietro alle quinte; tutto ciò di cui vi dovete preoccupare è di essere sicuri che ogni requisiti per la vostra trasformazione sia installata ed operativa. Potete fare molti tipi diversi di trasformazioni, e ci sono molti modi di trasformare i dati.

La suite di OpenOffice.org offre un’eccellente trasformazione del contenuto di Microsoft, così che se state eseguendolo su una piattaforma non-Microsoft, questo è un modo eccellente di trasformare quel contenuto. Abbiamo usato anche wvWare (http://wvware.sourceforge.net /) piuttosto con successo come un altro modo di trasformare contenuto. Tutti queste opzioni sono disponibili; comunque, loro non sono banali da installare. Una volta che sono installati, le persone di solito risultano soddisfate, trovando trasformazioni di alta qualità come quando usano un server Microsoft.

Raccomandiamo di pensare precisamente quello che volete trasformare prima e di dare poi un sguardo al codice sorgente di Portal Trasforms per vedere se potete trovare una trasformazione che faccia il lavoro per voi.

schema = BaseSchema +  Schema((
    TextField('body',
              searchable=1,
              required=1,
              primary=1,
              default_output_type='text/html',
              allowable_content_types=('application/msword',),
              widget=RichWidget(label='Body'),
              ),
    ),
    marshall=PrimaryFieldMarshaller(),
    )

allowable_content_types=('application/msword','application/pdf'),

Testare il tipo di contenuto

Per esaminare il vostro tipo di contenuto, avete bisogno di ravviare Plone, assicurarvi che il prodotto sia registrato come al solito, ed installato usando lo schermo Add/Remove Products. Per aggiungere un nuovo documento Word, andate all’interfaccia di Plone e nella casella a discesa selezionate Document Word; è abbastanza ovvio visto che vedrete anche un piccolo logo di Word.

Successivamente, selezionate il vostro file dal File System, e cliccate Salva per caricare il vostro file. Una volta che questo è stato fatto, il file sarà caricato, e sarà portato nella pagina di vista. Questo può prendere un po’ di più di quanto vi aspettate – avete caricato il documento nel server e poi effettuato la trasformazione. Ma sarà portato alla pagina di vista dal vostro tipo di contenuto, e certamente sarà mostrato in HTML, come mostrato in figura 13-4.

Figura 13-4. Il file caricato

Ora che è caricato, vorrete modificarlo; per questo, la vostra scommessa migliore è usare External Editor. Se avete installato External Editor sul vostro client locale, cliccate l'icona di matita nell'angolo in alto a destra, e il file si aprirà in Word, come mostra in Figura 13-5. Ora potete alterare e modificare il vostro documento Word. Ogni volta che salvate il file, verrà caricato all’interno di Plone e verrà trasformato.

Figura 13-5. Il documento caricato in Word

Suggerimento

Vedi

• http://sf.net/projects/archetypes
• http://www.logilab.org/projects/portaltransforms/documentation

Andare oltre: scrivere tipi di contenuto in un diagramma UML

Così avete un tipo di contenuto complicato e l’idea di scriverlo a mano vi sta annoiando? Bene, niente paura, perché ArchGenXML è qui! Questo è un prodotto pulito che permette di scrivere il vostro contenuto in un tool di modellizzazione grafico UML e svilupparsi un prodotto dritto da questo. Filippo Auspberg sviluppò ArchGenXML, e Jens Klein ha offerto della documentazione eccellente. Con gentile permesso, riprodurremo alcuni di quei diagrammi qui.

Il tool di modellazione UML deve supportare uno sistema standard Extensible Markup Language (XML) di generazione chiamato XML Metadata Interchange (XMI). Questo tool è stato testato con i seguenti programmi:

• ObjectDomain (commerciale, con una demo gratis per 30 classi) presso http://www.objectdomain.com
• ArgoUML (libero) presso http://argouml.tigris.org
• Poseidon (commerciale, basato su ArgoUML) presso http://www.gentleware.com
• Sybase Powerdesigner (commerciale, demo download) presso http://www.sybase.com

Ci sono lievi differenti proprietà di esportazione per ognuno di questi, ma se date un sguardo negli esempi di ArchGenXML, vedrete esempi di output dai tools UML. La figura 13-6 mostra un progetto di classe che espone alcuni oggetti: room, person project, resource e task. Ci sono relazioni fra tutti questi oggetti, e c'è regolare codice Python specificato su alcuni degli oggetti.

Figura 13-6. Un esempio complesso di ArchGenXML

Il modo più rapido di esaminare questo è andare nella cartella di ArchGenXML sul vostro File System che avete ottenuto dall'originale installazione e poi modificatelo nella cartell