Default-Workflow

In Kapitel 3 habe ich den Default-Workflow und die Standardeinstellungen bei der Veröffentlichung von Inhalten behandelt. Dort habe ich für jeden Zustand im Workflow dessen Sicherheit und Einstellungen beschrieben. Aber da ein Bild mehr sagt als tausend Worte, sehen Sie in Abbildung 8.2 diese Workflow-Zustände.

Abbildung 8.2. Default-Workflow in Plone für Inhalte

Abbildung 8.2 zeigt die Hauptzustände und -übergänge. Die grau gepunktete Linie in dieser Abbildung stellt eine Art Trennung zwischen Sicherheitsbereichen dar. Links von dieser Linie sind es die Besitzer von Inhalten, die damit interagieren, und rechts von der Linie interagieren normalerweise die Prüfer mit den Inhalten.

Wie beim Kreditkartenbeispiel ist auch hier ein zugehöriger Satz an Rechten für den Default-Workflow vorhanden. Tabelle 8.4 gibt alle Rechte und Zustände an.

Tabelle 8.4. Rechte im Default-Workflow

Wie Sie in Tabelle 8.4 sehen können, werden Inhalte nur dann standardmäßig vor anderen verborgen, wenn sie im Zustand Privat sind. Inhalte im Zustand Veröffentlicht kann nur der Manager bearbeiten. Im Abschnitt "Rechte bearbeiten", der weiter unten folgt, werde ich Ihnen zeigen, wie Sie diese Rechte ganz einfach über das Web ändern können.

Ordner-Workflow

Ebenfalls in Kapitel 3 habe ich den Ordner-Workflow beschrieben, als ich die Veröffentlichung von Inhalten behandelt habe. Aber wie ich dort bemerkt habe, gibt es für Ordner keinen offenen Zustand. Deswegen haben Sie einen etwas einfacheren Workflow, wie in Abbildung 8.3 gezeigt.

Abbildung 8.3. Ordner-Workflow in Plone für Inhalte

Weitere Workflows

Für eine Plone-Website sind zahlreiche Workflows verfügbar, darunter ein privater Workflow, ein Community-Workflow, ein One-Step Publication-Workflow usw. ZopeZen enthält einen Workflow, und PloneCollectorNG enthält ebenfalls einen Workflow. DCWorkflow enthält vier Workflows.

Zurzeit enthält das Produkt PloneWorkflows im Collective-Projekt auf SourceForge (http://sf.net/projects/collective) zwei Workflows: den Community-Workflow und den One-Step Publication-Workflow. Der Community-Workflow ähnelt bis auf ein paar Änderungen dem Plone-Workflow. Der One-Step Publication-Workflow verfügt über zwei Zustände: privat und veröffentlicht.

Im Moment gibt es keine einfache Möglichkeit, Workflows zu installieren bzw. zu deinstallieren, ebenso wenig wie es eine wirklich einfache Methode gibt, den Zustand von Inhalten zu wechseln. Wenn Sie z.B. den One-step Publication-Workflow bei einem vorhandenen Zustand installieren, müssen Sie auch die Zustände für alle Objekte reparieren und sie in einen der neuen Zustände überführen. In diesem Fall ist das wahrscheinlich einfach: Alles im Zustand Veröffentlicht sollte so bleiben, wie es ist, und alles andere sollte in den Zustand Privat wechseln.

Ausgangszustand setzen

Um den Ausgangszustand zu setzen, gehen Sie zum States-Reiter und prüfen die verfügbaren Zustände. Neben einem der Zustände werden Sie ein Sternchen wie in Abbildung 8.6 sehen.

Abbildung 8.6. Ausgangszustand für diesen Workflow setzen

Auf dieser Seite setzen Sie den Ausgangszustand für Ihren Workflow, indem Sie das Kontrollkästchen neben dem Zustand markieren und dann auf Set Initial State klicken. Alle Inhalte, die diesen Workflow benutzen, werden in diesem Ausgangszustand erzeugt. Alle anderen schon erzeugten Inhalte bleiben in ihrem Zustand. Bei einer späteren Zustandsänderung wird dieser Zustand nicht verändert. Zu jedem Workflow können Sie nur einen Ausgangszustand einstellen.

Zustände bearbeiten

Unter dem States-Reiter werden die in diesem Workflow vorhandenen Zustände aufgelistet. Am Anfang dieses Kapitels habe ich erklärt, dass ein Zustand ein Objekt zu einem bestimmten Zeitpunkt darstellt. Jeder Zustand hat eine eindeutige ID, normalerweise ein einfaches Verb wie pending (offen) oder published (veröffentlicht). Um einen Zustand hinzuzufügen, geben Sie eine ID ein und klicken unten auf der Seite auf Add.

Außerdem werden Sie die folgenden Optionen sehen:

• Title: Der Titel des Zustands wird in Ihrer Plone-Site angezeigt. Er ist ein benutzerfreundlicher Name für den Zustand.
• Description: Dies ist eine längere Beschreibung des Zustands. Momentan können die Benutzer diese Beschreibung nicht sehen, aber das kann sich in Zukunft noch ändern.
• Possible transitions: Hier werden die möglichen Übergänge aufgelistet, die aus diesem Zustand heraus erfolgen können. Diese Liste erscheint nur dann, wenn Sie tatsächlich einen Übergang im System haben. Wählen Sie einfach die Übergänge aus, die aus diesem Zustand erfolgen müssen. Durch die Wahl eines Übergangs für diesen Zustand machen Sie diesen Zustand zum Startpunkt des gewählten Übergangs.

Um einen Zustand zu ändern, geben Sie die Änderungen ein und klicken dann auf Save, um diese zu bestätigen. Der Permissions-Reiter wird geöffnet und zeigt die Rechte an, die auf dem Objekt in diesem Zustand angewendet werden. Das kann bedeuten, dass sich die Rechte des Objekts ändern, wenn es in diesen Zustand übergeht. Das Formular ist ziemlich selbsterklärend. Damit ein anonymer Benutzer das Objekt sehen kann, markieren Sie die Kästchen für View und Anonymous und klicken Sie auf Save, wie in Abbildung 8.7 zu sehen ist.

Abbildung 8.7. Seite für Zustandsrechte

Wenn Sie die Rechte an einem bestimmten Workflow-Zustand ändern, haben Sie ein Problem, das Sie lösen müssen. Diese neuen Workflow-Rechte werden nicht auf den vorhandenen Inhalten in diesem Zustand gesetzt. Diese Inhalte haben weiterhin die alten Workflow-Rechte, und Sie müssen sie aktualisieren. Wenn Sie mit Ihren Änderungen fertig sind, gehen Sie in die Workflow-Ausgangsseite und klicken auf Update Security Settings, wie in Abbildung 8.4 gezeigt wird. Es kann eine Weile dauern, diese Aktualisierung durchzuführen, je nachdem, wie viele Objekte davon betroffen sind.

Der Variables-Reiter gestattet Ihnen die Zuweisung eines Wertes an eine Variable, falls das Objekt in diesem Zustand ist. Der Workflow bestimmt für jeden Zustand die Liste der verfügbaren Variablen. Weitere Informationen dazu finden Sie im Abschnitt "Variablen bearbeiten".

Übergänge bearbeiten

Der Transitions-Reiter listet die Übergänge auf, die in diesem Workflow erfolgen können. Zu Beginn dieses Kapitels habe ich Ihnen gezeigt, wie ein Übergang Änderungen darstellt, die auf dem Objekt erfolgen. Jeder Übergang hat einige Variablen, die auf der Zusammenfassungsseite angezeigt werden. Um einen Übergang hinzuzufügen geben Sie eine ID ein und klicken unten auf der Seite auf Add, wie in Abbildung 8.8 zu sehen ist.

Abbildung 8.8. Seite mit Übergangsdetails

Wenn Sie nun auf einen Übergang klicken, öffnen Sie die Details zu diesem Übergang:

• Title: Dies ist der Titel des Übergangs.
• Description: Dies ist die detaillierte Beschreibung des Übergangs.
• Destination state: Das ist der Zielzustand dieses Übergangs. Der Ursprungszustand wird bei der Zuweisung des Übergangs an einen Zustand definiert.
• Trigger type: Hiermit wird angegeben, wodurch der Übergang ausgelöst wird. Automatic bedeutet, dass er sofort ausgelöst wird, wenn dieser Zustand erreicht wird. Initiated by user action ist die am häufigsten gewählte Einstellung und bedeutet, dass ein Benutzer den Übergang ausgelöst hat, indem er einen Link angeklickt hat.
• Script (before): Dieses Skript wird ausgeführt, bevor der Übergang erfolgt.
• Script (after): Dieses Skript wird ausgeführt, nachdem der Übergang erfolgt ist.
• Guard: Dies ist der Wächter bei diesem Zustand (wird gleich erklärt).
• Display in actions box: Hier wird angegeben, wie dieser Übergang in Plone dargestellt wird. Eine Eingabe an dieser Stelle garantiert, dass der Übergang auch als Aktion eingegeben wird. Sie erhalten diesen Übergang als Aktion, wenn Sie nach Aktionen fragen.

Unter diesen Werten ist der Zielzustand recht interessant. Ich habe zwar schon erwähnt, dass Übergänge normalerweise den Zustand wechseln, aber das muss nicht so sein. Da bei jedem Übergang Skripten ausgeführt werden können und etwas protokolliert werden kann, ist es manchmal nützlich, den Zustand nicht zu wechseln. Betrachten Sie als Beispiel hierfür den Abschnitt "Änderungen mit einem Workflow verfolgen" weiter unten in diesem Kapitel. Wenn Ihr Übergang den Zustand wechselt, wählen Sie den neuen Zustand als Zielzustand.

Ein Übergang kann mehrere Startpunkte, aber nur ein Ziel haben. Wenn Sie mehrere Ziele brauchen, müssen Sie mehrere Übergänge anlegen. Sie können auch Skripten angeben, die vor und nach diesem Übergang ausgeführt werden. Zwei häufige Beispiele hierfür sind das Verschieben eines Objekts im Workflow und das Senden von Benachrichtigungen per E-Mail. Beide Beispiele werden im Abschnitt "Häufige Aufgaben und Beispiele" behandelt.

Bevor ein Übergang erfolgt, wird er von einem Sicherheitswächter (Guard) überprüft, um sicherzustellen, dass der Benutzer auch das Recht hat, den Übergang auszuführen. Dieser Wächter besteht aus den folgenden drei Komponenten:

• Permission(s): Dies sind die notwendigen Rechte. Mehrere Rechte sollten durch ein Semikolon (;) voneinander getrennt sein.
• Role(s): Dies sind die notwendigen Rollen. Mehrere Rollen sollten durch ein Semikolon (;) voneinander getrennt sein.
• Expression: Dies ist ein Workflow-Ausdruck. Weitere Informationen dazu finden Sie im Abschnitt "Workflow-Ausdrücke bearbeiten" weiter unten in diesem Kapitel. Für jeden angegebenen Wert muss der Wächter den Wert logisch wahr ergeben, bevor weitergemacht werden kann. Falls ein Test bei einem der Werte fehlschlägt, wird der Übergang nicht ausgeführt. Meistens sind bei einem Wächter nur ein oder zwei Werte angegeben.

Variablen bearbeiten

Der Variables-Reiter listet die Variablen auf, die im Workflow erzeugt und geändert werden. Bisher habe ich diese Variablen nicht groß erwähnt, sondern habe mich auf Zustände und Übergänge konzentriert. In diesem Abschnitt geht es nun um Variablen.

Es ist nicht immer möglich, alle in einem Workflow benötigten Informationen in Zuständen und Übergängen zu kapseln. Und ich rate Ihnen auch nicht, das unbedingt zu versuchen. Stattdessen können Sie Variablen verwenden, um einige Workflow-bezogene Informationen zu speichern. Im Kreditkartenbeispiel könnte die Rechnung z.B. auf mehrere Arten beglichen werden, z.B. per Online-Banking, Scheck usw. Sie könnten den Betrag (z.B. 100 Euro) in einer Variablen speichern. Sollte die Rechnung abgelehnt oder verändert werden, würde dieser Betrag aktualisiert. Der wesentliche Punkt bei einer Variablen ist der, dass man etwas hat, das sich zwischen den Zuständen und Übergängen ändern kann.

Klicken Sie nun wieder in der Workflow-Hauptseite auf den Variables-Reiter, um eine Liste aller Variablen zu bekommen. Um eine Variable hinzuzufügen, geben Sie eine Variablen-ID ein und klicken unten auf der Seite auf Add. Um zu bestimmen, in welchem Zustand ein Objekt zu einer bestimmten Zeit ist, speichert DCWorkflow den aktuellen Zustand in einer Variablen im Objekt. Standardmäßig lautet der Name dieser Variable review_state.

Alle Workflow-Variablen verfügen über die folgenden Eigenschaften:

• Description: Dies ist eine Beschreibung der Variablen.
• Make available to catalog: Diese Variablen werden in einer Liste platziert, auf die der Katalog zugreifen kann. Dabei werden kein Index oder Metadaten zum Katalog hinzugefügt. Das müssen Sie weiterhin von Hand machen.
• Store in workflow: Hiermit wird bestimmt, ob die Information im Workflow oder im Objekt gespeichert wird.
• Variable update mode: Dies bestimmt, wann die Variable aktualisiert wird.
• Default value: Das gibt einen Standardwert als String an.
• Default expression: Dies ist der Standardwert als Ausdruck. Wenn er vorhanden ist, wird er an Stelle des String-Wertes verwendet (weitere Informationen finden Sie im Abschnitt "Workflow-Ausdrücke bearbeiten" weiter unten in diesem Kapitel).
• Info. guard: Das sind Sicherheitseinstellungen beim Zugriff auf diese Variable. Diese Wächtereinstellungen ähneln jenen eines Übergangs. Hierbei wird der Wächter allerdings dann ausgeführt, wenn auf die Variable zugegriffen wird.

Worklists bearbeiten

Der Worklists-Reiter bietet einen Zugriff auf alle Worklists, die in diesem Workflow zugewiesen sind. Eine Worklist ist eine Methode, den Workflow nach Informationen über die Anzahl von Objekten in diesem Workflow zu fragen. Ich möchte z.B. gern den Workflow einfach nach allen ausstehenden Kreditkartenrechnungen für mich fragen.

Um eine Worklist hinzuzufügen, geben Sie eine ID ein und klicken auf Add. Alle Worklists verfügen über folgende Eigenschaften:

• Description: Dies ist eine Beschreibung der Worklist.
• Cataloged variable matches: Dies ist der Wert, auf den die Workflow-Variable eines Objekts passen muss, damit es zu dieser Worklist hinzugefügt wird. Die passende Variable ist die Workflow-Zustandsvariable, die in der Variablenliste angegeben ist (der Standardname dieser Variablen lautet review_state).
• Display in actions box: Diese Information soll in der Benutzerschnittstelle angezeigt werden. Die Eingabe eines Wertes an dieser Stelle stellt auch sicher, dass der Übergang als Aktion eingetragen wird. Sie erhalten diesen Übergang als Aktion, wenn Sie nach den Aktionen fragen.
• Guard: Dies ist ein Wächter für den Zugriff auf diese Worklist.

Kommen wir wieder zum Kreditkartenbeispiel zurück: Wenn ich gerne wüsste, welche Kreditkartenrechnungen ich alle überprüfen muss, könnte ich diese Information in einer Worklist angeben. Zuerst würde die Variable review_state den aktuellen Zustand jedes Elements enthalten. Alle zu überprüfenden Kreditkartenrechnungen wären im Zustand review (überprüfen). Zweitens würde ich eine Worklist namens review_queue hinzufügen, und der Variablenwert wäre pending (offen). Nun würde ich die Worklist nach allen Elementen in review_queue fragen.

Obwohl Worklists eine bequeme Art sind, diese Information zu speichern, benutzt Plone selbst keine Worklists. Stattdessen benutzt Plone direkt ZCatalog, um Objekte abzufragen, die sich in einem Workflow befinden. Da die DCWorkflow-Worklist das Katalog-Werkzeug verwendet, ist das Ergebnis das gleiche.

Skripten bearbeiten

Der Scripts-Reiter listet die Skripten auf, die in diesem Workflow verfügbar sind. Diese Liste ist eigentlich ein normaler Ordner im ZMI, und Sie können darin fast alles hinzufügen. Der Hauptgrund dafür ist vermutlich der, ein Skript hinzuzufügen, um eine kompliziertere Behandlung von Übergängen zu bewerkstelligen, d.h., Sie sollten an dieser Stelle nur Script (Python)-Objekte hinzufügen.

Um ein Skript unter dem Scripts-Reiter hinzuzufügen, wählen Sie im Add-Dropdown-Menü die Option Script (Python) und geben dem Skript eine ID. Dem Skript wird genau ein Objekt übergeben, nämlich das Ausdrucksobjekt des Basis-Workflows. Weitere Informationen darüber finden Sie im Abschnitt "Workflow-Skripten bearbeiten" weiter unten in diesem Kapitel. Wenn Sie z.B. auf das eigentliche Objekt im Workflow zugreifen müssen, können Sie ein Python-Skript wie folgt benutzen:

##parameters=state_change
obj = state_change.object

Was in diesem Skript passiert, entscheidet dessen Entwickler. Sie können hier fast alles machen. Sie können Ereignisse auslösen, und Sie können auf andere Workflows und Übergänge zugreifen. Einige Beispielskripten finden Sie in den Abschnitten "Benachrichtigungen per E-Mail versenden" und "Objekte verschieben" im weiteren Verlauf dieses Kapitels. Wenn das Skript ausgeführt wird, wird es unter dem Benutzer ausgeführt, der den Übergang eingeleitet hat. Sie könnten dem Skript eine Proxy-Rolle zuweisen, wenn es unter einem anderen Benutzer ausgeführt werden muss. Was die Übergänge angeht, so können Sie dieses Skript in den Einstellungen zu script (after) und script (before) an beliebig viele Übergänge zuweisen. Sie können das Skript entweder vor oder nach einem Übergang ausführen.

Rechte bearbeiten

Der Permissions-Reiter listet die von diesem Workflow verwalteten Rechte auf. Diese Rechte haben Sie schon bei der Behandlung von Zuständen gesehen. Unter diesem Reiter setzen Sie die Liste der Rechte, die in diesen Zuständen verwaltet werden. Ein neues Recht fügen Sie hinzu, indem Sie es im Dropdown-Menü auswählen und auf Add klicken.

Wie können Sie ein veröffentlichtes Dokument bearbeiten?

Nun, im Default-Workflow können Sie ein schon veröffentlichtes Dokument nicht bearbeiten, es sei denn, Sie haben die Rolle eines Managers. Wenn Sie dem Besitzer des Dokuments erlauben, es zu bearbeiten, sollten Sie es wirklich nochmal prüfen. Allerdings scheint das eine häufige Frage zu sein, und man kann es ganz schnell so einrichten, dass das geht. Klicken Sie im ZMI auf portal_workflow, und wählen Sie den Contents-Reiter. Dann klicken Sie auf plone_workflow und wählen den States-Reiter. Und schließlich klicken Sie auf published und wählen den Permissions-Reiter. Markieren Sie das Kästchen, das einem Besitzer erlaubt, Portal-Inhalte zu ändern.

Klicken Sie auf Save Changes, um Ihre Rechte zu speichern. Da Sie die Sicherheitseinstellungen aktualisiert haben, müssen Sie auf portal_workflow klicken, den Contents-Reiter wählen und auf Update security settings klicken. Dadurch werden alle Objekte in Ihrer Site aktualisiert, und es wird garantiert, dass Ihre Rechte auf den vorhandenen Objekten angewendet wurden. Ab jetzt können Dokumente von ihren Besitzern bearbeitet werden, während sie im Zustand Veröffentlicht sind.

Workflow-Skripten bearbeiten

Skripten bieten dem Entwickler die Möglichkeit, bei der Ausführung eines Übergangs eine zusätzliche Anwendungslogik auszuführen. Das kann fast alles sein, was Sie tun möchten. Sie könnten z.B prüfen, ob gewisse Bedingungen erfüllt sind (z.B. ob die Rechtschreibung beim Dokument geprüft wurde) oder ob spezielle Aktionen ausgeführt wurden. Wenn ein Objekt seinen Zustand wechselt, wird das Skript aufgerufen.

Wenn ein Skript aufgerufen wird, wird ihm ein zusätzlicher Parameter übergeben. Dieser zusätzliche Parameter ermöglicht den Zugriff auf alle Arten von übergangsbezogenen Elementen und Attributen. Dieser Parameter wird auch state_change-Parameter genannt und hat folgende Attribute:

• status: Dies ist der Status des Workflows.
• object: Dies ist das Objekt, das im Workflow einen Zustandswechsel durchmacht.
• workflow: Dies ist das aktuelle Workflow-Objekt zu dem betroffenen Objekt.
• transition: Dies ist das aktuell ausgeführte Übergangsobjekt.
• old_state: Dies ist der Ursprungszustand des Objekts.
• new_state: Dies ist der Zielzustand des Objekts.
• kwargs: Dies sind die Schlüsselargumente, die an die Methode doActionFor übergeben werden.
• getHistory: Dies ist eine Methode, die keine Parameter hat und eine Kopie der Workflow-Historie des Objekts zurückgibt.
• getPortal: Dies ist eine Methode, die keine Parameter hat und das Plone-Wurzelobjekt zurückgibt.
• ObjectDeleted(ordner): Dies sagt dem Workflow, dass das Objekt, dessen Zustand wechselt, gelöscht wurde. Diese Methode erwartet das Objekt, zu dem der Benutzer zurückkehren soll. Übergeben Sie der Ausnahme den Ordner, zu dem der Benutzer umgeleitet werden soll (siehe den Abschnitt "Objekte verschieben" weiter unten in diesem Kapitel).
• ObjectMoved(neuesObjekt, neuesObjekt): Dies sagt dem Workflow, dass das Objekt, dessen Zustand wechselt, verschoben wurde. Übergeben Sie der Ausnahme den Ordner, zu dem der Benutzer umgeleitet werden soll (siehe den Abschnitt "Objekte verschieben" weiter unten in diesem Kapitel).
• getDateTime: Dies ist eine Methode, die keine Parameter hat und das zum Übergang gehörende DateTime-Objekt zurückgibt.

Um z.B. herauszufinden, zu welchem Zielzustand ein Übergang erfolgt und wann, können Sie das folgende Script (Python)-Objekt verwenden, das Ihnen genau diese Information liefert. Dieses Skript schreibt die Information über den Übergang in die Protokolldatei:

##parameters=state_change
st = 'From %s to %s on %s' % (
    state_change.old_state,
    state_change.new_state,
    state_change.getDateTime())
context.plone_log(st)

Bei der Zuweisung eines Skripts an einen Übergang haben Sie zwei Möglichkeiten: before und after. Wie diese Namen schon besagen, wird ein Skript, das an before zugewiesen wird, ausgeführt, bevor der Übergang erfolgt. Das eignet sich für Skripten, die prüfen, ob etwas noch vor dem Übergang passieren soll, die also z.B. testen, ob ein weiteres abhängiges Objekt oder eine Seite hochgeladen wurde oder ob etwas frei von Tippfehlern ist. Das an after zugewiesene Skript wird ausgeführt, nachdem der Übergang beendet ist. Sollte aber eine irgendwann ausgelöste, nicht abgefangene Ausnahme in einem Skript auftreten, dann führt das dazu, dass der Übergang fehlschlägt, das Objekt in seinem ursprünglichen Zustand bleibt und dem Benutzer die Ausnahme angezeigt wird.

Workflow-Ausdrücke bearbeiten

In diesem Kapitel haben Sie durchgehend Werte gesehen, die als Workflow-Ausdrücke ausgedrückt werden können. Der Wert beispielsweise, der einer Variablen zugewiesen wird, ist das Ergebnis eines Workflow-Ausdrucks. Dieser Ausdruck ist nichts Ungewöhnliches, sondern lediglich ein TAL-Ausdruck (Template Attribute Language) mit einigen anderen verfügbaren Variablen. TAL-Ausdrücke haben Sie bereits in Kapitel 5 kennen gelernt, d.h., Sie sollten mit diesen Ausdrücken und ihren Optionen wie Python-, String- und Pfadausdrücken vertraut sein.

Anders als bei den normalen TAL-Ausdrücken werden einige zusätzliche Parameter mit Bezug auf den konkreten Workflow über den Namespace übergeben. Der Namespace eines Workflow-Ausdrucks enthält Folgendes:

• here: Dies ist das Objekt, das im Workflow einen Zustandswechsel erfährt.
• container: Dies ist der Container des Objekts, das im Workflow den Zustandswechsel erfährt.
• state_change: Dies ist das Zustandswechselobjekt, das im Abschnitt "Workflow-Skripten bearbeiten" erwähnt wurde.
• transition: Dies ist der gerade ausgeführte Übergang; identisch mit state_change.transition.
• status: Dies ist der ursprüngliche Zustand, identisch mit state_change.old_state.
• workflow: Dies ist der Workflow für dieses Objekt.
• scripts: Dies sind die in diesem Workflow verfügbaren Skripten.
• user: Dies ist der Benutzer, der den Übergang ausführt.

Schreiben über das ZMI

Der vielleicht einfachste, aber arbeitsintensivste Weg, einen Workflow zu schreiben, ist der über das ZMI. Auch, wenn das ZMI viele Leute in den Wahnsinn treibt, ist es doch eine einfach Art, die Optionen einzustellen. Leider ist es aber so, dass Sie, nachdem Sie mit dem Schreiben im ZMI angefangen haben, in diesem Paradigma gefangen sind. Mit anderen Worten: Es gibt keinen einfachen Weg, diesen Workflow im Dateisystem zu bearbeiten oder zu verändern. Natürlich habe ich aber weiter oben in diesem Kapitel beschrieben, wie Sie einen Workflow über das Web bearbeiten können. Eine andere Alternative ist, den Workflow in einem UML-Tool als Zustandsdiagramm zu erstellen und mit ArchGenXML (siehe Kapitel 13) zu generieren.

Um einen Workflow aus dem ZMI zu exportieren, klicken Sie auf portal_workflow und dann auf den Contents-Reiter. Wählen Sie die gewünschten Workflows aus, indem Sie die Kästchen links im ZMI markieren, und klicken Sie dann auf import/export. Im oberen Teil der Exportseite wählen Sie Download to local machine und klicken auf export. Es wird eine Datei mit der Erweiterung .zexp erzeugt, die gespeichert und weiterverteilt werden kann. Bei der Wahl von XML Format hat die Datei das Format XML (Extensible Markup Language) mit der Erweiterung .xml.

Wenn Sie einen Workflow mit der Erweiterung .zexp oder .xml erhalten, können Sie diesen Workflow sehr einfach in Ihr Plone importieren. Kopieren Sie die Datei im Dateisystem ins Import-Verzeichnis von Zope. Das kann das Verzeichnis von der Wurzelinstanz oder von Zope sein.

Klicken Sie dann auf portal_workflow, wählen Sie den Contents-Reiter, und klicken Sie auf import/export. Im unteren Teil der Seite werden Sie ein kleines Formular sehen, in dem man einen Import-Dateinamen angeben kann. Geben Sie hier den Dateinamen ein, und lassen Sie die Option Take ownership of imported objects markiert. Klicken Sie auf den Import-Button, um den Workflow zu importieren. Nun wird der Workflow importiert und bekommt den Namen, der beim Export angegeben wurde.

Workflows in Python schreiben

Der vermutlich beliebteste Weg, Workflows zu schreiben, ist der, es direkt in Python zu tun, weil man dies vollständig in Python machen und leicht verteilen kann. Erstellen Sie zuerst ein Python-Modul im Dateisystem. Ganz oben in der Datei importieren Sie die passenden Werkzeuge wie folgt:

from Products.CMFCore.WorkflowTool import addWorkflowFactory
from Products.DCWorkflow.DCWorkflow import DCWorkflowDefinition

Als Zweites erstellen Sie eine Funktion, die den Workflow erzeugt. Anhang A listet das API zum Schreiben eines Workflows etwas detaillierter auf. Aber Sie könnten auch mogeln und sich all die tollen Beispiele anschauen, die im PloneWorkflow-Projekt der Collective-Sammlung verfügbar sind (http://sf.net/projects/collective) oder sogar die, die in Plone enthalten sind. Beispiel:

def sample(id):
    """ Sample workflow """
    ob = DCWorkflowDefinition(id)
    ob.states.addState('private')
    ob.states.addState('public')
    # add transitions
    return ob

Und schließlich registrieren Sie den Workflow wie folgt im System:

addWorkflowFactory(sample,
                   id='sample_workflow',
                   title='Sample workflow')

Dieses Skript muss nun Teil einer Produkt-Installation werden. Kapitel 12 behandelt das Schreiben und die Installation von Produkten.

Nun gibt es dafür natürlich auch eine Abkürzung namens DCWorkflowDump. Dabei wird für Sie der Code aus dem ZMI genommen und in ein Python-Modul geschrieben. Den Quellcode für DCWorkflowDump finden Sie im Collective-Projekt unter http://sf.net/projects/collective, aber Sie finden auch eine Zip-Datei des Codes auf der Website zum Plone-Buch unter http://plone-book.agmweb.ca.

Um DCWorkflowDump zu installieren, packen Sie die Datei aus und kopieren das Verzeichnis namens DCWorkflowDump in das Products-Verzeichnis Ihrer Plone-Installation. Dass Sie im richtigen Verzeichnis sind, merken Sie, wenn das Products-Verzeichnis auch das DCWorkflow-Verzeichnis und andere Dinge enthält. Dann starten Sie Ihre Plone-Instanz neu.

Nachdem Sie Plone neu gestartet haben, gehen Sie im ZMI zu dem bestimmten Workflow, wo Sie einen neuen Reiter namens dump bemerken werden. Klicken Sie auf diese Seite, um zu diesem Dump-Schirm zu gelangen, und klicken Sie dann auf Dump it!, um den Workflow auf den Bildschirm zu schreiben. Dabei wird Ihr Workflow für Sie in Python formatiert. Speichern Sie die Datei in Ihr Produkt, und Sie haben eine Python-Datei, die Sie manipulieren können. Dieses Produkt ist ein tolles Werkzeug, weil es Ihnen erlaubt, den Workflow im ZMI zu erstellen und dann mit Hilfe von Python zu verteilen und zu ändern.