Module vom Typ 'parent'

Die Module vom Typ 'parent', oder kurz Parent-Module, kommen nur in Workflow-Schritten vom Typ 'parent' vor. Sie dienen dort dazu, die Steuerung über den Subworkflow unter dem Parent-Schritt zu übernehmen.

Ein Parent-Modul muss wie ein normales Modul auch die Modulfunktion ``main'' besitzen. Der Inhalt ihrer $control_args ist derselbe wie bei normalen Modulen und es gibt keine Rückgaben. Diese wird aufgerufen, falls der Parent-Schritt selbst der aktuell angezeigte und verarbeitete Workflow-Schritt ist, d.h. seine Schrittnummer der Wert von $param[wf_step] ist (siehe ). Im Gegensatz zu normalen Modulen wird aber das Parent-Modul i.a. Funktionen zum Lesen und Verändern des Status des Subworkflows verwenden. Typische Funktionen zum Status-Lesen hierbei sind 'wf_step_status', 'wf_subworkflow_status', 'wf_step_durchlaufnummer'. Zum Aktivieren bzw. Deaktivieren des Subworkflows könnten die Funktionen 'wf_subworkflow_open' bzw. 'wf_subworkflow_close' benutzt werden. Jedoch ist die indirekte Aufruf-Variante mit Global-Actions (z.B. via 'wf_globalaction_form_element' siehe ) vorzuziehen.

Das Schließen des Subworkflows unter dem Parent-Schritt sollte jedoch i.a. dem Subworkflow selbst, d.h. den End_Schritten des Subworkflows vorbehalten bleiben, so dass sich der Parent-Schritt meist nur um die Aktivierung kümmern muss. Jedoch kann der Parent-Schritt über die Funktion 'wf_notify' (siehe ) abfragen, ob eine Schließung des Subworkflows im aktuellen php-Skript-Aufruf vor Ausführung des Parent-Moduls erfolgte (z.B. durch Global-Action-Mechanismus). Der Funktionsaufruf von 'wf_notify($parentstep)' gibt ein Array zurück, in dem der Parameter 'subworkflow_has_closed' gleich '1' ist, falls eine Schließung des Subworkflows in diesem Aufruf erfolgte. Ebenso ist der Parameter 'subworkflow_has_opened' gleich '1', falls eine Aktivierung des Subworkflows in diesem Aufruf erfolgte.

Weiterhin verwalten Parent-Module oft zusätzliche temporäre Daten (meist gespeichert in der Relation 'workflow_temp_data'), die für den aktuellen Subworkflow-Durchlauf relevant sind, d.h. Daten die Verbindung zwischen den Workflow-Status-Informationen und den Anwendungsdaten herstellen. Ein Beispiel hierfür wäre die Nummer einer Klausur, die in einem bestimmten Subworkflow-Durchlauf durchgeführt wird. Einerseit ist diese Nummer ein Attribut in den Anwendungsdaten über die Klausuren, andererseits ist sie mit dem aktuellen Subworkflow-Durchlauf verbunden. Es steht den Parent-Modulen jedoch frei, ob sie diese Daten in der Relation 'workflow_temp_data' über die in beschriebenen Funktionen ('wf_temp_data...') oder in den Anwendungs-Relationen (bei passendem Anwendungs-Datenbank-Schema) selbst speichern.

Um einerseits den Schritten eines Subworkflows diese zusätzlichen temporären Informationen zugänglich zu machen und andererseits kurze Informationen über den aktuellen Subworkflow-Status anzuzeigen, hat jedes Parent-Module eine Modulefunktion mit Namen ``head''. Bevor die Module des aktuellen Schrittes ausgeführt und angezeigt werden, werden rekursiv von allen indirekten Parent-Schritten die 'head'-Funktion in den Parent-Module aufgerufen (vgl. ). Damit hat der Benutzer auch durch die Anzeige einen groben Überblick über die Subworkflow-Struktur. Vor allem aber dienen die head-Funktionen der Übergabe der temporären Informationen an die Schritte des Subworkflows, sowie einiger Subworkflow-Status-Information, die nur der Parent-Schritt kennt, an das globale Workflow-System. Der 'head'-Modulfunktion steht es dabei frei auch Änderungsmöglichkeiten (wie in der ``main''-Modulfunktion) dem Benutzer anzubieten.

Das Array $control_args für den Aufruf der 'head'-Funktion eines Parent-Moduls eines Parent-Schrittes hat folgenden Inhalt (vgl ):

• [step_nr:]Schrittnummer des jeweiligen Parent-Schrittes
• [parent_args:]Array, das die temporären Variablen enthält, die von den indirekten Parents dieses aufgerufenen Parents übergeben werden. Beim Aufruf des top-Schrittes ist dieses Array leer. Der aktuelle Schritt erhält schließlich alle diese Parameter gesammelt von allen seinen indirekten Parents.
• [output_off:]boolsches Flag, falls 'true' sollte Ausgabe auf Stdout während des Aufrufes des Parent-Moduls unterlassen werden, um von den Modulen des Schrittes selbst die HTML-Ausgabe bestimmen zu lassen ($param[wf_step_position]=''Modulpage, vgl ).

Die Rückgabe jeder 'head'-Funktion eines Parent-Moduls sollte ein Array sein, das folgende Parameter enthält:

• [parent_args:]Array von Variablenzuweisungen, die von diesem Parent an alle (rekursiven) Kinder (d.h. an darunterliegende Parents des Schrittes und den eigentlichen Schritt selbst) über $control_args[parent_args] (siehe oben) übergeben werden. Das hier zurückgegebene Array wird dabei mit den bereits vorhandenen Variablendefinitionen der höheren indirekten Parents vereinigt.
• [subworkflow_mode_old:]boolsches Flag, falls 'true', so wird dem Workflow-System angezeigt, dass hier nicht der aktuelle Durchlauf des unter dem Parent-Schritt liegenden Subworkflows bearbeitet wird, sondern ein ehemaliger, bereits abgeschlossener Durchlauf. Dann wird vom Workflow-System kein Workflow-Status (z.B. Schritt offen oder erledigt, Subworkflow aktiv oder nicht) unter diesem Parent-Modul angezeigt bzw. keine Möglichkeiten zur Änderung des Workflow-Status gegeben.
• [strict_subworkflow:]boolsches Flag, falls 'true', wird von diesem Parent bestimmt, dass Module in Schritten des Subworkflows darunter nur dann aufgerufen werden, d.h. Änderungen nur dann möglich sind, wenn dieser Subworkflow auch aktiv ist.

Die zurückgegebenen Parameter 'subworkflow_mode_old' und 'strict_subworkflow' haben die in beschriebene Wirkung.

 

Wie normale Module können auch Parent-Module weitere Modulfunktionen enthalten, die aufgerufen bei $param[wf_step_position]=''Modulepage'' (siehe ) selbst eine ganze HTML-Seite allein erzeugen.