Einblick in Archetypes

Eine ganze Menge von großartigen Beispielen sind für Archetypes verfügbar, deshalb möchte ich anstatt ein neues zu erfinden, ArchExample zeigen, das beim Archetypes-Repository dabei ist. Darin wird ein neuer Inhaltstyp namens Article eingeführt, anhand dessen die Stärken von Archetypes demonstriert werden.

Article.py enthält den Kern des Sourcecodes, und Sie werden sehen, dass der Code ziemlich anders aussieht als die früheren Codebeispiele. Eine wichtige Neuerung ist die Verwendung von Schemata. Der Begriff Schema ist hier angelehnt an den Schemabegriff aus der Datenbankentwicklung.

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

Dieses Stück Code zeigt ein Attribut namens blurb innerhalb des Inhaltstyps, das den Datentyp string hat und das im Edit-Formular als TextArea angezeigt werden soll. Ich werde später auf alle Optionen für Felder und Kontrollelemente (Widgets) eingehen. Abbildung 13.1 zeigt den neuen Inhaltstyp Article im Einsatz beim Editieren.

Abbildung 13.1. Edit-Formular des neuen Inhaltstyps

Mit lediglich vier Codezeilen wurde zu unserem Inhaltstyp ein Feld hinzugefügt. Für jedes Standard-Formelement in Plone gibt es eine Felddefinition in Archetypes; alle "langweiligen" Aufgaben wie z.B. Feldvalidierung, Fehlerbehandlung, richtige Darstellung werden vom Archetypes-Framework für Sie erledigt. Um die Einfachheit zu demonstrieren, ändern Sie einfach die Beschriftung (Label) des Kontrollelements (Widget) auf Article blurb und deklarieren das Eingabefeld als Muss-Feld (required). Diese Änderungen erreichen Sie durch unten stehenden Code:

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

Es wurde der Parameter required = 1 hinzugefügt, der das Feld zu einem Muss-Feld macht, sowie ein label-Parameter, der an das Widget übergeben wird. Wenn Sie Plone neu starten und einen neuen Artikel hinzufügen, werden Sie Ihre Änderungen sehen. Das Feld blurb hat nun eine andere Beschriftung, und durch den roten Punkt beim Eingabefeld wird deutlich, dass es sich um ein Muss-Feld handelt.

Abbildung 13.2. Das veränderte Eingabefeld

Dies ist nicht nur eine kosmetische Änderung, denn sie spiegelt die Modifikation im darunter liegenden Schema wider, und das ist die wirkliche Stärke von Archetypes. Wenn Sie dies mit dem Schreiben von Python-Produkten vergleichen, werden Sie sehen, dass viel von der Knochenarbeit des sich ständig wiederholenden Kodierens entfällt und im Hintergrund durch das Framework erledigt wird. Man kann es auch so formulieren: Wenn Sie für einen Inhaltstyp das Schema definieren können, ist das Erstellen der Software keine Hexerei mehr. Außerdem sind Änderungen an existierenden Inhaltstypen leicht durchzuführen, was einem bei den schnelllebigen Projekten der heutigen Zeit sehr zugute kommt.

Wenn Sie Änderungen am Code durchführen, um die folgenden Beispiele auszuprobieren, müssen Sie Plone neu starten, um jene wirksam zu machen. Mehr Informationen darüber gibt es später im Abschnitt 'Entwickeln mit Archetypes'.

Schemata, Felder und Kontrollelemente

In Archetypes hat jeder Inhaltstyp, der im Prinzip eine registrierte Python-Klasse mit ganz bestimmten Basisklassen ist, ein Schema, das Felddefinitionen enthält, die ihrerseits noch ihre Darstellung über Kontrollelemente (Widgets) definieren.

Abbildung 13.3 zeigt die Beziehung zwischen Schemata, Feldern und Kontrollelementen.

Abbildung 13.3. Schemata, Felder und Kontrollelemente

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)
         )

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

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

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'),
          )

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

from validation.validators.validator import RangeValidator
from validation import validation
 
# the RangeValidator takes a name for the validator
# and a start and end value
validAge = RangeValidator("validAge", 0, 150)
validation.register(validAge)

validators=("isInt","validAge"),

from Products.validation.interfaces import ivalidator
from DateTime import DateTime

class DateRangeValidator:
   __implements__ = (ivalidator,)

   def __init__(self, name, begindate, enddate):
       self.name = name
       self.begindate=begindate
       self.enddate=enddate

   def __call__(self, value, *args, **kwargs):

       if not isinstance(value, DateTime):
           value = DateTime(value)

       if self.begindate < value and value < self.enddate:
           return True
       else:
           return "the given date is not between %s and %s"%(str(self.begindate), str(self.enddate))

christmas = DateRangeValidator("ChristmasHolidays",
    DateTime('2004-12-18 00:00:00'),
    DateTime('2005-01-09 00:00:00'),)
validation.register(christmas)

validators=("ChristmasHolidays",)

Definition von Ansichten (Views) und Aktionen (Actions) in der Basisklasse

Archetypes erzeugt für jeden Inhaltstyp die Standard-Ansichten und -Aktionen basierend auf Anforderungen, die den meisten Anwendungen gerecht werden. Diese Standard-Aktionen sind view, edit und properties. In Ihrem Produkt werden Sie keine Page Templates dazu finden, denn diese Views werden automatisch zum Zeitpunkt der Darstellung umgesetzt. Aber selbstverständlich können Sie für Ihre Klasse eigene Ansichten programmieren und anpassen.

Meistens ist es so, dass man für den Inhaltstyp eine eigene view-Ansicht programmieren will, denn die Standardansicht zählt einfach nur die Attribute des Schemas mit den dazugehörigen Werten auf und erhebt auch nicht den Anspruch, eine perfekte Seite zu sein, wohingegen die edit- und properties-(Metadaten-)Ansichten von Haus aus den meisten Ansprüchen gerecht werden.

Im Prinzip wird für jeden Inhaltstyp eine Klasse geschrieben, vergleichbar mit dem Schreiben von Klassen im letzten Kapitel, wobei pro Plone-Produkt beliebig viele solcher Klassen enthalten sein können. Jede Klasse, die einen Inhaltstyp beschreibt, erbt von einer Archetypes-spezifischen Basisklasse, in den meisten Fällen entweder von BaseContent oder BaseFolder. Erstere Basisklasse wählt man für alle einfachen Inhaltstypen, wie zum Beispiel Article, während BaseFolder zum Einsatz kommt, wenn man einen Inhaltstyp schreiben will, der seinerseits andere Objekte enthalten soll (im Zope-Jargon folderish object genannt). In diesen Basisklassen ist alles enthalten, was vom Archetypes-Framework benötigt wird, so dass man sich in der eigenen Klasse auf das Wesentliche konzentrieren kann.

Wie ich jetzt zeigen werde, besteht dies im Wesentlichen aus zwei Teilen. Zuerst definieren wir eine Aktion, indem wir diese in der Factory-Type-Information (siehe letztes Kapitel) in Form eines Attributs namens actions definieren, das eine Liste der einzelnen Aktionsdefinitionen enthält. Zum Beispiel:

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,)
                },)

Zweitens benötigen Sie ein PageTemplate für den View namens article_view. Der Name des Templates muss zu der URL im action-Parameter passen, denn unter diesem Namen wird das Page Template in der Plone-Skin gesucht. In diesem Fall wird das passende Page Template im skins/archexample-Verzeichnis unseres Produkts abgelegt. Im Anhang B können Sie ein vollständiges Listing dieses Page Templates finden. Beim Schreiben dieses Views haben Sie volle Gestaltungsfreiheit.

Um die Änderungen wirksam werden zu lassen, muss Plone neu gestartet werden. In diesem Fall wurde eine Aktion neu definiert, die während des Installationsprozesses des Produkts im portal_types-Tool registriert wird. Deswegen muss das Produkt zusätzlich mit dem QuickInstaller reinstalliert werden, indem Sie in Plone auf Plone konfigurieren klicken.

Alle Elemente in der Factory-Type-Information (FTI) können als gleichnamige Attribute der Klasse überschrieben werden. Um zum Beispiel das content_icon-Element der FTI zu überschreiben, können Sie in der Klasse einfach ein Attribut mit Namen content_icon definieren. Sehen Sie sich dazu folgendes Beispiel an:

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

Überschreiben von Standardmethoden

In Tabelle 13.2 habe ich die Möglichkeit des Überschreibens von Standardmethoden erwähnt, die in einem Inhaltstyp auftauchen können, etwa accessor oder mutator. Dies ist eine Option für Fortgeschrittene, die es erlaubt,den Mechanismus zu beeinflussen, wie Felder editiert werden.

Wie im Sourcecode im letzten Kapitel greifen Sie auf die Attribute niemals direkt zu, sondern über die dazugehörigen Get- und Set-Methoden, die in Archetypes accessors und mutators genannt werden. Diese Zugriffsmethoden werden automatisch von Archetypes generiert. Im Falle eines Feldes namens blurb heißen diese beiden Methoden getBlurb und setBlurb, das Präfix set oder get wird dem großgeschriebenen Feldnamen vorangestellt.

Jedoch werden Sie vielleicht im Accessor oder Mutator etwas anderes machen wollen. Nehmen wir an, Sie wollen beim Speichern den Wert eines Feldes filtern und korrigieren, wie zum Beispiel die Schreibweise Ihrer Firma korrigieren oder beim Ändern eines Feldinhaltes auch andere Felder ändern. Dies können Sie erreichen, indem Sie die oben erwähnten Standardmethoden überschreiben. Im folgenden Beispiel werden Sie eine neue Methode namens getSpecialBlurb schreiben, die im blurb-Wert den Text Perl durch Python ersetzt, bevor der Wert zurückgegeben wird.

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

Außerdem müssen Sie noch Ihr Feld ändern, damit es diese Methode verwendet:

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

In diesem Beispiel wird bei jedem lesenden Zugriff auf das blurb-Feld in einer View- oder Edit-Seite der Wert von getSpecialBlurb zurückgegeben. Archetypes weiß, dass es diese Methode verwenden soll, weil deren Name im accessor-Parameter der Felddeklaration festgelegt ist. Ein bisher noch nicht erwähnter Griff in die Trickkiste kommt hier zum Einsatz: Um von getSpecialBlurb den Feldinhalt zu bekommen, muss man zuerst das Feldobjekt bekommen und dort die get-Methode aufrufen, was man durch den etwas komplexen Ausdruck blurbself.getField('blurb').get(self) erreicht. Dieses Muster, ein Feldobjekt zu holen und dann eine Methode darauf aufzurufen, ist in Archetypes recht gebräuchlich.

Das praktische Ergebnis davon ist nun, dass, sobald jemand das Wort Perl im Feld blurb eingibt, dieses durch Python ersetzt wird.

Den Rest des Inhaltstyps zusammensetzen

Ich habe nun alle Hauptelemente des Inhaltstyps behandelt. Listing 13.1 zeigt den gesamten Code. Sie werden bemerken, dass der Rest des Programmcodes kompakter ist als der Python-Code im letzten Kapitel, da Archetypes sehr viel im Hintergrund für Sie erledigt.

Listing 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)

Abgesehen von den import-Anweisungen am Beginn und dem Schema, habe ich alle Elemente des Sourcecodes behandelt, mit der Ausnahme von registerType. Diese Funktion registriert die Klasse mit Ihrem Produkt im Archetypes-Framework. Jedes Produkt kann beliebig viele Inhaltstypen registrieren. So wird diese Funktion registerType mit zwei Parametern aufgerufen: der Klasse und dem Namen des Produktes. Der zweite Parameter ist optional und wird nur in Ausnahmefällen benötigt, da die Funktion registerType von der Klasse auf das Produkt schließen kann. In diesem Beispiel ist der Produktname in der Datei config.py definiert; es ist allgemein üblich, Einstellungen an zentraler Stelle in einer config.py-Datei innerhalb des Produkts vorzunehmen, wie zum Beispiel:

Listing 13.2. Die Konfigurationsdatei von 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'),
    ))

Die Variable ARTICLE_GROUPS ist eine Liste von Wertepaaren für das Vokabular des group-Feldes in Article, wobei jeweils der erste Wert bei Auswahl im Feld gespeichert wird und der zweite als zugehöriger Text in der Auswahlliste erscheint. Man kann allerdings auch eine einfache Liste von Werten als Vokabular angeben, wenn man nicht zwischen den Werten und deren Beschriftung unterscheiden muss. In Fall dieses Beispiels sieht der erzeugte HTML-Code für das groups-Feld folgendermaßen aus:

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

Ich möchte hier noch auf die Verwendung von globals() hinweisen. Dies ist eine eingebaute Python-Funktion, die alle Symbole aus dem globalen Namespace zurückgibt. Sie wird hier verwendet, um den Pfad zum skins-Verzeichnis im Filesystem zu berechnen, so dass Sie ein File-System-Directory-View davon für das Skins-Tool erstellen können. Das Produktinitialisierungsmodul __init__.py ist dadurch also wesentlich einfacher. Mit einem neuen Zusatz sehen die Funktionen process_types und listTypes nun so aus:

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

Die listTypes-Funktion aus dem Archetypes-Framework gibt alle Typdeklarationen zurück, die bisher im angegebenen Produkt registriert wurden. Diese Liste wird von process_types noch weiter behandelt, die dann die Inhaltstypen, Konstruktoren und Factory-Type-Informationen (FTI) zurückgibt, die sodann beim CMF mit der Funktion ContentInit registriert werden. Vieles ist ähnlich wie beim Schreiben von reinen Python-Produkten für das CMF, nur dass diese Funktionen das Ganze ein wenig vereinfachen.

Schließlich gibt es noch die install-Funktion im Skript Extensions/Install.py. Im Gegensatz zum __init__.py-Modul, das aufgerufen wird, wenn das Produkt beim Hochstarten von Zope registriert wird, wird das Installationsskript aufgerufen, wenn ein Produkt in einer bestimmten Plone-Instanz zum Beispiel durch den QuickInstaller installiert wird. Dieses Skript vereinfacht sich durch Archetypes ebenfalls wesentlich, da die meiste Arbeit durch installTypes und install_subskin abgehandelt wird. Der Begriff Subskin ist ein wenig irreführend - eigentlich ist damit ein Skin-Layer gemeint.

Listing 13.3. Installationsskript

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()

Das vollständige Paket von ArchExample ist auf der Homepage des Autors des Plone-Buches unter http://plone-book.agmweb.ca zum Download verfügbar, Sie können es durch Auspacken in Ihrem Plone ausprobieren. Wie Sie gesehen haben, ist dieser Inhaltstyp schnell und einfach zu entwickeln und auch leicht zu ändern, ohne viel Code zu schreiben.

Verwendung von eindeutigen Schlüsseln (Unique Ids, UIDs)

Das Konzept von eindeutigen Schlüsseln ist einfach, aber hat in Zope bislang gefehlt. Ursprünglich glaubten Zope-Entwickler, dass der Pfad auf ein Objekt für dessen Adressierung ausreichend sei; unglücklicherweise hat sich das als unzureichend herausgestellt. Was passiert zum Beispiel, wenn ein Objekt verschoben wird? Alle Referenzen auf dieses Objekt würden nun ins Leere verweisen, da sich durch das Verschieben der Pfad ändert. Mit Hilfe der eindeutigen Schlüssel steht eine elegante Lösung des Problems zur Verfügung. Archetypes vergibt und speichert automatisch für jedes Objekt eine UID, die in einem speziellen Katalog namens uid_catalog indiziert wird.

Sie können diesen uid_cataog im ZMI ansehen. Dieser ist dem portal_catalog ziemlich ähnlich, nur dass er ausschließlich die für die Verwaltung und Suche von UIDs nötigen Indizes enthält. Es ist ziemlich einfach, ein Objekt aufgrund seiner UID über den uid_catalog zu erhalten. Sie müssen lediglich über den UID-Index nach der entsprechenden UID suchen; bei jedem Objekt können Sie dessen UID mit Hilfe der Funktion UID() abfragen. Das nachfolgende Python-Script kann jedes Objekt aus dem Katalog suchen, vorausgesetzt, Sie kennen dessen UID.

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

Wirklich nützlich sind die eindeutigen Schlüssel bei der Verwaltung von Referenzen zwischen Objekten. Nehmen wir an, Sie wollen von Ihrem Artikel aus verschiedene Bilder referenzieren, die sich in Ihrem Portal befinden. Wenn diese Bilder Archetypes-Ojekte sind, können Sie wie folgt ein ReferenceField zu Ihrem Schema hinzufügen:

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

Der User bekommt nun eine Dropdown-Liste mit den Titeln aller Archetype Image-Objekte und kann eines auswählen. Im Hintergrund werden beim Speichern Referenzen zu den Zielobjekten angelegt. Verantwortlich für die Referenzlogik in Archetypes ist die ReferenceEngine; der interessierte Leser möge hierfür den Code in Archetypes/ReferenceEngine.py studieren. Im Archetypes-Subversion-Archiv unter http://svn.plone.org gibt es das Produkt ACME, das viele der fortgeschrittenen Programmiertechniken wie die Referenzen demonstriert. Die Installation ist aber aufgrund von weiteren Produkten, die benötigt werden, nicht ganz einfach.

Anpassen von Widgets

Eine häufig gestellte Frage ist: "Warum macht dieses Widget das eigentlich?" oder: "Warum sieht dieses Widget so aus?" Oft lautet die Antwort: "Weil es so geschrieben ist - Sie können es sich ja anpassen." Da die Widgets das sind, was der Kunde sieht, ändern sich die Anforderungen oft, so dass dem Entwickler hier die Flexibilität von Archetypes zugute kommt.

Alle Widgets bestehen einerseits aus einer Python-Klasse - die vorgegebenen Widgets kann man in Archetypes/Widget.py sehen - und die dazugehörigen Page Templates in Archetypes/skins/archetypes/widgets. Wenn Sie im ZMI auf portal_skins klicken und dort archetypes/widgets wählen, sehen Sie alle mit Archetypes gelieferten Widgets. Unglücklicherweise hat das portal_skins-Tool von CMF einen kleinen Bug. Weil die Widgets in einem Unterverzeichnis sind, kann man leider nicht einfach eines der Templates ändern. Das ist aber nicht so schlimm, Sie können in Ihrem Produkt einen eigenen Skin-Layer definieren und dann in der Widget-Deklaration des Schemas spezifizieren, dass das Widget mit einem anderen Makro dargestellt werden soll. Jedes Widget-Objekt hat ein macro-Attribut, das definiert, welches Makro das Widget darstellen soll, und das als Pfad-Ausdruck zum Widget Page Template spezifiziert wird.

Nun ist der Begriff macro irreführend, denn das Attribut verweist auf ein Page Template, das seinerseits drei Makros enthält: view, edit und search. Diese Makros sind für das Anzeigen Ihres Widgets in den verschiedenen Situationen zuständig.

Das view-Makro ist eine benutzerfreundliche Ansicht mit rein lesendem Zugriff und wird zum Beispiel in der base_view-Ansicht pro Feld angezeigt. Das edit-Makro wird in der Bearbeitungsansicht angezeigt und ist das Makro, mit dem der Benutzer die Daten für das einzelne Feld eingibt. Es kommt zum Beispiel in der base_edit-Ansicht zum Einsatz. Das search-Makro wird verwendet, wenn Sie eine Suchmaske für Ihren Inhaltstyp zusammenstellen wollen; es sieht häufig wie das edit-Makro aus, muss aber nicht unbedingt so aussehen . Ein Stringfeld kann zum Beispiel in einem RichWidget eingegeben werden, aber der Suchbegriff dazu könnte mit einem StringWidget eingegeben werden.

Nun, für unser Beispielprodukt wollen wir ein StringField für die E-Mail-Adresse einer Person verwenden, die in der view-Ansicht als klickbarer E-Mail-Link dargestellt wird. Dafür benötigen wir ein neues view-Makro; die Makros für edit und search können wir vom StringWidget nehmen. Dazu erstellen Sie ein neues Page Template namens email_widget.pt in der Skin Ihres Produkts. Für edit und search werden einfach die entsprechenden Makros des StringWidgets aufgerufen:

<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>

Für view erzeugen Sie einen mailto:-Link, den Sie durch folgende kleine Änderung erreichen:

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

Nach dem Definieren des neuen Page Templates mit Ihrem eigenen Code können Sie einfach dessen Namen in der Widget-Deklaration als macro-Parameter angeben. Im folgenden Codebeispiel definieren Sie das E-Mail-Feld als StringField mit zugehörigem StringWidget wie üblich, nur dass Sie noch das zu verwendende Makro explizit angeben:

StringField('E-Mail',
    validators = ('isEmail',),
    widget = StringWidget(
        label='E-Mail',
        macro='email_template'
    )
)

Bis jetzt haben Sie lediglich das Makro eines bereits vorhandenen Widgets geändert. Ein ganz neues Widget zu erstellen erfordert das Schreiben einer eigenen Widget-Klasse und deren Registrierung. Alle Widgets haben eine gemeinsame Basisklasse. Im folgenden Beispiel schreiben wir ein eigenes Modul namens EmailWidget.py und speichern es in das ArchExample-Verzeichnis. Es enthält die neue Widget-Klasse und deren Registrierung. Beachten Sie, dass die macro-Property des Widgets auf das email_template voreingestellt ist:

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 E-Mail field',
    used_for=('Products.Archetypes.Field.StringField',)
)

Um das neue Widget in Ihrer Article-Klasse zu verwenden, importieren Sie EmailWidget und geben es wie folgt im widget-Parameter zum Feld an:

from EmailWidget import EmailWidget
 
StringField('E-Mail',
    validators = ('isEmail',),
    widget = EmailWidget(
        label='E-Mail',

    )
)

Das Entwickeln von ordnerartigen Objekten (Folderish Objects)

Sie haben vermutlich schon oft mit ordnerartigen Objekten in Plone gearbeitet, ohne sich dessen bewusst zu sein. Ein ordnerartiges Objekt ist eines, das ähnliche Eigenschaften wie ein Ordner aufweist, nämlich dass es seinerseits Unterobjekte enthalten kann. Das Erstellen eines ordnerartigen Objekts ist nichts Besonderes - die Klasse muss lediglich von einer besonderen Basisklasse erben, um die entsprechenden Fähigkeiten zur Verfügung zu stellen, und schon kann man zu unserem Objekt neue Unterobjekte hinzufügen.

Ordnerartige Objekte sind aus verschiedenen Gründen nützlich. Sie stellen einen einfachen Weg dar, um Sammlungen von einzelnen Objekten zu erzeugen. Sie erlauben außerdem, dass Plone-Benutzer ihre speziellen Inhaltstypen über die gewohnte Plone-Oberfläche verwalten können, ohne dass Sie dafür speziell programmieren müssen. Generell ist es am besten, den Ordner einfach zu halten, und die Logik sollte in Ihren Objekten und in deren Workflow enthalten sein. Natürlich gibt es Ausnahmen dazu, und ein klassisches Beispiel ist die Familie der Bugtracker, CMFCollector und PloneCollectorNG, die beide komplexe ordnerartige Objekte sind, die einiges an Logik für die einzelnen Einträge bieten.

Der einfachste Weg, um ordnerartige Objekte zu erstellen, ist wiederum die Verwendung von Archetypes. Sie haben in den vorigen Beispielen gesehen, dass BaseContent alle nötigen Standardarbeiten für "normale" Objekte erledigt. Nun gibt es auch eine Klasse BaseFolder, die die entsprechenden Aufgaben für ordnerartige Objekte übernimmt. Außerdem besitzen Ordner ein eigenes Basisschema BaseFolderSchema. Auf den Punkt gebracht: Um einen ordnerartigen Inhaltstyp zu erstellen, ändern Sie die Basisklasse auf BaseFolder und fügen sie zum Schema BaseFolderSchema hinzu. Ein einfaches Beispiel für einen ordnerartigen Inhaltstyp sehen Sie hier:

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

Wenn Sie beabsichtigen, eine große Menge von Unterobjekten in einem Ordner zu speichern, dann ist die Klasse BaseFolder weniger geeignet, da diese Klasse von der Zope-Basisklasse Folder erbt, die nicht auf große Datenmengen ausgelegt ist. Für große Mengen von Unterobjekten empfiehlt sich die Verwendung von Binary-Tree-Ordnern, die die Unterobjekte intern in einem Binärbaum effizienter speichern statt in einem Python-Dictionary, wie dies bei Folder der Fall ist. In diesem Fall lassen Sie Ihre Klasse von BaseBTreeFolder erben und nehmen als Basisschema BaseBTreeFolderSchema. Was die Produktentwicklung betrifft, sind die beiden gleich zu programmieren, nur dass auch bei einer Anzahl von mehr als 100.000 Objekten der BtreeFolder gut skaliert.

Arbeiten mit Microsoft Office-Dateien

Der Umgang mit Microsoft-Office-Dateien wie zum Beispiel Word oder Excel ist ein Fluch, mit dem jedes Content-Management-System irgendwann einmal konfrontiert wird. Aber dies ist der Fall mit mit verschiedenen Dateiformaten - Microsoft Office, OpenOffice.org, Portable Document Format (PDF), Imagedateien usw. Der Umgang mit diesen Dateiformaten auf Webseiten verursacht normalerweise einige Probleme; dies ist natürlich wohlbekannt. Das Editieren ist umständlich, da durch das Anklicken das Dokument heruntergeladen wird oder - noch schlimmer - in Ihrem Webbrowser geöffnet wird. Wenn Sie es fertig editiert haben, müssen Sie das Dokument abermals auf die Website hochladen, was wiederum eine Runde des Herumklickens bedeutet. Wenn das Dokument endlich online ist, ist dieses meistens nicht suchbar, weil Binärdateien nicht indiziert werden. Außerdem können Sie das Dokument nicht online betrachten, weil der Webbrowser das jeweilige Datenformat ohne spezielle Plugins nicht darstellen kann.

Es gibt einige Lösungen, um das Problem des Editierens von Inhalt zu lösen. Wenn Sie weiter annehmen, dass die meisten Ihrer Anwender Windows verwenden, dann kann die Verwendung von WebDAV mit Komplikationen verbunden sein, da Microsofts Implementation des WebDAV-Clients (Web Folders) von fraglicher Qualität ist. Hingegen erfüllt der External Editor diese Funktion recht gut. Wenn Plone dem External Editor mitteilen kann, dass es sich bei dem editierten Objekt zum Beispiel um eine Word-Datei handelt, wird der External Editor das Dokument mit Word öffnen.

Und für den Rest enthält Archetypes ein Transformationspaket namens Portal Transforms, das die Transformation von Inhaltstypen beherrscht. Dies kann ein Dokument in einem bestimmten Datenformat in HTML transformieren, wonach es katalogisiert werden kann, und als HTML kann es auch im Webbrowser dargestellt werden. Dies funktioniert durch die Verwendung eines externen Transformationsprozesses, um die Daten umzuwandeln und das Ergebnis auszulesen und darzustellen. Wenn Sie zum Beispiel Plone unter Windows (auf dem Server) verwenden, dann nimmt Portal Transforms ein auf dem Server installiertes Microsoft Office als COM-Server, um die Word-Datei in HTML umzuwandeln.

All dies passiert im Hintergrund. Sie müssen lediglich sicherstellen, dass die für die Transformationen benötigten Komponenten installiert sind und funktionieren. Es gibt verschiedene Typen von Transformationen, und oft gibt es mehr als eine Möglichkeit, Daten zu transformieren.

Das OpenOffice-Paket stellt hervorragende Transformationen von Microsoft Office-Daten zur Verfügung (oft sogar besser als MS Office selbst!) und bietet somit auch auf Nicht-Microsoft-Plattformen die Möglichkeit, Office-Daten zu verarbeiten. Ich habe auch schon wvWare (http://wvware.sourceforge.net/) verwendet, ein Kommandozeilen-Werkzeug, das es ermöglicht, verschiedene Microsoft-Formate in HTML zu übersetzen. All diese Optionen stehen Ihnen zur Verfügung; oft sind die Komponenten aber nicht einfach zu installieren. Nach dem Aufsetzen der Komponenten berichten Benutzer, dass die besten Ergebnisse mit Microsoft Office und Openoffice.org als Backend der Transformationen erzielt werden.

Ich empfehle, zuerst genau zu überlegen, was transformiert werden soll, und dann einen Blick in den Quellcode von PortalTransforms zu werfen, um zu sehen, ob Sie eine geeignete Transformation für Ihre Zwecke finden.

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'),

Testen des Inhaltstyps

Um den Inhaltstyp zu testen, starten Sie Plone neu, stellen sicher, dass Ihr Produkt wie üblich registriert ist, und installieren es in Ihrem Portal mit Produkte hinzufügen/löschen. Nun legen Sie eine Instanz Ihres neuen Inhaltstyps an.

Nun selektieren Sie eine Word-Datei aus Ihrem Dateisystem und klicken Save, um sie zu Plone hochzuladen. Anschließend wird diese Datei hochgeladen, und Sie können das Resultat sehen. Verlieren Sie hier nicht die Geduld, denn dieser Vorgang kann länger dauern, denn zusätzlich zum normalen Upload der Daten muss Word als externes Programm aufgerufen werden, um die HTML-Datei mit eventuell eingebetteten Bildern zu erzeugen. Wenn alles richtig arbeitet, sollten Sie Ihr Word-Dokument als HTML etwa wie in Abbildung 13.4 sehen.

Abbildung 13.4. Die hochgeladene Datei

Nun da Sie das Dokument im Plone haben, wollen Sie es auch editieren können. Hierzu empfiehlt sich der Einsatz von External Editor. Wenn Sie External Editor auf Ihrem Arbeitsplatz installiert haben, klicken Sie auf das Bleistiftsymbol in der oberen rechten Ecke, und die Datei wird in Word geöffnet, wie in Abbildung 13.5 zu sehen ist. Sie können nun das Dokument ändern und editieren; jedes Mal, wenn Sie die Datei speichern, wird diese im Hintergrund zu Plone hochgeladen und wiederum zu HTML transformiert.

Abbildung 13.5. Das Dokument in Word geöffnet

Fortgeschrittenes Entwickeln: Erstellen von Inhaltstypen mit UML

Nun haben Sie ein Produkt mit mehreren komplizierten Inhaltstypen und finden die Idee, diese manuell zu schreiben, langweilig? Nun, keine Angst, denn ArchGenXML ist hier! Dies ist in hilfreiches Produkt, das es Ihnen erlaubt, Ihre Plone-Applikation mit UML in einem UML-Modellierungstool Ihrer Wahl zu modellieren und aus diesem Modell ein lauffähiges Plone-Produkt zu generieren.

Philipp Auersperg hat das ArchGenXML-Projekt begonnen, und Jens Klein hat vieles an Code und Dokumentation dazu beigetragen. Ich werde in diesem Abschnitt einige der Fähigkeiten von ArchGenXML, das zur Drucklegung dieses Buches in der Version 1.2 vorliegt, vorstellen.

Um mit ArchGenXML zusammenarbeiten zu können, muss ein UML-Tool den Export des Modells als XMI (XML-Anwendung zum Austausch von Modell-Metadaten) unterstützen. ArchGenXML wurde erfolgreich mit den folgenden Produkten getestet:

• ObjectDomain (kommerziell, die Demoversion erlaubt das Editieren von bis zu 30 Klassen), erhältlich unter http://www.objectdomain.com
• ArgoUML (frei), erhältlich unter http://argouml.tigris.org
• Poseidon (kommerziell, basierend auf ArgoUML, kostenlose Community-Edition verfügbar), erhältlich unter http://www.gentleware.com
• Sybase Powerdesigner (kommerziell, zeitlich limitierte Demoversion verfügbar), erhältlich unter http://www.sybase.com

Der Export von XMI-Modelldateien wird von den verschiedenen UML Tools leicht unterschiedlich gehandhabt (zum Beispiel exportiert ObjectDomain keine Statemachines). Aber wenn Sie einen Blick auf die ArchGenXML-Beispiele werfen, sehen Sie einige Beispielmodelle, die die Funktionalität von ArchGenXML demonstrieren. Abbildung 13.6 zeigt ein einfaches Modell mit einigen Klassen und Beziehungen.

Abbildung 13.6. Ein komplexes Beispiel eines Datenmodells

Abbildung 13.7. Zustandsdiagramm für die Klasse Project

Der einfachste Weg, um daraus ein lauffähiges Plone-Produkt zu generieren, besteht darin, in das Verzeichnis samples/PloneBook in Ihrem ArchGenXML-Verzeichnis zu wechseln und den unten stehenden Befehl aufzurufen. Damit wird aus dem ArgoUML-Modell ein lauffähiges Plone-Produkt namens Project erzeugt.

python ../../ArchGenXML.py product.zargo Product

Sie müssen sodann das Produkt in Ihren Products-Ordner Ihrer Plone-Installation kopieren und Zope neu starten. Wenn Sie einen Blick in das eben generierte Produkt werfen, werden Sie sehen, dass alles Notwendige für Sie generiert wurde: die Klassendateien, die Modulinitialisationsdatei __init__.py und die Skripten zum Installieren des Produktes in Ihre Plone-Instanz im Extensions-Verzeichnis. Im neu gestarteten Plone müssen Sie nun lediglich Plone konfigurieren wählen und das neu verfügbare Produkt installieren, und schon können Sie mit den neuen Inhaltstypen experimentieren. Sie werden die Attribute, die im Datenmodell für die Klassen vergeben wurden, im Edit-Schirm der Inhaltstypen wiedererkennen.

Abbildung 13.8. Das frisch generierte Produkt im Einsatz

Was passiert mit den manuellen Änderungen, die Sie an Ihrem Produkt-Quellcode vornehmen, wenn Sie mit ArchGenXML noch einmal das Modell über Ihr modifiziertes Produkt generieren? Nun, ArchGenXML stellt zwar kein Roundtripping zur Verfügung, aber es behält bestimmte Änderungen bei, die Sie im Quellcode vornehmen. So werden Methoden, die Sie in der Klassendefinition modifiziert oder hinzugefügt haben, beibehalten; weiters werden Sie im Quellcode geschützte Codebereiche finden (mit #code-section markiert), die beim Generieren beibehalten werden. Ebenso werden sämtliche Page Templates beibehalten, die innerhalb des skins-Ordners generiert wurden.

Welche UML-Konzepte werden von ArchGenXML unterstützt? ArchGenXML stellt Ihnen eine Reihe von Konzepten aus der UML-Spezifikation für die Plone-Entwicklung zur Verfügung, ich möchte sie hier kurz anhand des oben erwähnten Beispiels anführen:

• Klassen: ArchGenXML generiert aus jeder Klasse im Modell den Code für genau einen Inhaltstyp. Klassen, die als Abstrakt markiert wurden, werden als nicht instanziierbare Inhaltstypen generiert (z.B. Resource).
• Methoden: Jede Methode im Modell entspricht einer Methode innerhalb der Klassendefinition des Inhaltstyps. Methoden, die den Stereotyp view oder form besitzen, werden hingegen als Page Template mit einer dazugehörigen Action generiert (z.B project_overview in der Klasse Project). Methoden, die als Stereotyp action besitzen, werden nur als Actions generiert.
• Attribute werden als Feld in der Schemadefinition generiert.
• Interfaces werden als Python-Interface-Deklarationen generiert. Klassen, die eine Realisationsbeziehung zu einem Interface besitzen, bekommen das in der Zope-Entwicklung übliche __implements__-Statement verpasst.
• Vererbung: Generalisierungsbeziehungen zwischen Klassen werden auch in Python als Vererbungsbeziehung generiert; Mehrfachvererbung wird unterstützt. Beispiel: Resource und Person bzw. Room.
• Aggregation und Composite: Diese beiden Beziehungen drücken sich in ordnerartigen Objekten aus. Die Klasse, die andere enthalten kann, wird als ordnerartiges Objekt generiert, das den Clientteil der Beziehung enthalten kann (mit Hilfe von allowed_content_types). Beispiel: Projekt-Resource für eine Aggregation oder Projekt-Task für ein Composite.
• Assoziationen werden als ReferenceFields generiert, wobei hier zwischen den Kardinalitäten 0..1 und 0..n unterschieden wird. Beispiel: Projekt-Person oder Task-Resource.
• Zustandsmodelle (Statemachines) werden als Workflow-Definition generiert, die automatisch beim Installieren des Produkts im Workflow-Tool eingerichtet und der entsprechenden Klasse zugeordnet wird. Beispiel: Das Zustandsdiagramm der Klasse Project

Das ist alles über das Rapid Development, was im Rahmen dieses Buches angeführt werden kann. Es gibt noch eine Reihe von Optionen in ArchGenXML. Viele Feineinstellungen können über Stereotypen und so genannte Tagged Values sowie Kommandozeilenparameter eingestellt werden. Eine umfangreiche und ständig wachsende Online-Dokumentation wurde von Jens Klein initiiert und ist auf plone.org unter http://plone.org/documentation/tutorial/archgenxml-getting-started zu finden.

Daten in einer SQL-Datenbank speichern

Für fast alles, was in diesem Buch gezeigt wurde, sind die Daten in der Zope Object Database (ZODB) gespeichert worden. Ich habe gezeigt, wie Daten im Dateisystem gespeichert werden, aber eine häufig gestellt Frage ist, wie Daten in einer relationalen Datenbank gespeichert werden können. Eine Speicherung in einer relationalen Datenbank lohnt sich vor allem dann, wenn folgende Tatsachen zutreffen:

• Ihre Datenstrukturen sind starr, und das Schema ändert sich selten (obwohl Archetypes diesen Aspekt abschwächt).
• Sie haben andere Applikationen, die Zugriff auf die relationale Datenbank haben oder benötigen.
• Sie haben Tools und andere Anforderungen, die bereits von einer relationalen Datenbank erfüllt werden.
• Sie haben eine große Menge an Daten, die oft verändert werden.

In einer eher traditionellen CGI-Umgebung werden Sie wahrscheinlich einige SQL-Statements schreiben, um die Daten aus einer relationalen Datenbank zu beziehen. Ähnliches erreichen Sie in Zope durch die Verwendung von ZSQL-Methoden. Diese sind in vielen Situationen nützlich und werden sehr ausführlich im Online-Zope-Buch auf zope.org und einigen anderen Büchern behandelt, aber sie bieten kein richtiges objektrelationales (OR) Mapping. ZSQL-Methoden speichern als Template das SQL-Statement und führen Abfragen aus, indem dieses SQL-Statement an die Datenbank abgesetzt wird. Dies ist recht nützlich, um einfache Abfragen durchzuführen, aber es eignet sich nicht, um ganze Objekte transparent in einer relationalen Datenbank abzuspeichern, und entspricht somit nicht der Gedankenwelt von Plone.

SQLStorage macht sich die Tatsache zunutze, dass Archetypes eine eigene konfigurierbare Schicht für das Speichern von Att