Module vom Typ 'normal'

Ein Modul vom Typ 'normal' beinhaltet keinerlei Workflow-Steuerungsfunktionalität. Es wird z.B. zur Verwaltung von Anwendungsdaten (z.B. Räume, Studenten einer Vorlesung) oder zum Ausführen bestimmter Aktionen bzgl. der eigentlichen Anwendung (z.B. Übungs-Scheine erstellen, Mail verschicken) verwendet.

Ein solches Modul muss nur eine ``main''-Modulfunktion enthalten. Hierbei wird unterschieden, ob das Modul für einen Workflow-Schritt oder eine Extrapage aufgerufen wird (boolscher Parameter 'isextrapage' in $control_args).

Falls es in einem Workflow-Schritt aufgerufen wird, so kann es im Array $control_args auf folgende Parameter zugreifen (vgl. ):

• [step_nr:]Schrittnummer des Schrittes, für den das Modul aufgerufen wird. Bei Schritten vom Typ ``normal'' z.B. interessant, um beim Aufruf der Funktion 'wf_temp_data_get' (siehe oben ) die eigenen temporären Daten zu finden oder auch um eindeutige Bezeichner in eigenen Form-Variablen zu wählen .
• [step_name:]Name des Schrittes, d.h. Wert des Attributes 'name' aus der Relation 'workflow_schritt', für den das Modul aufgerufen wird
• [parents:]Liste der Schrittnummern aller indirekten Parents des Schrittes, für den das Modul aufgerufen wird, vom direkten Parent bis zum top-Schritt.
• [isextrapage:]boolsches Flag, das hier stets 'false' ist, um anzuzeigen, dass das Modul innerhalb eines Workflow-Schrittes und nicht einer Extrapage aufgerufen wird. Dies bedeutet z.B. auch, dass der Parameter 'step_nr' als Schrittnummer und nicht als Extrapagenummer zu interpretieren ist.
• [subworkflow_mode_old:]boolsches Flag, das anzeigt, ob tatsächlich Daten des derzeit aktuellen Subworkflow-Durchlaufes bearbeitet werden ('false') oder Daten eines früheren Durchlaufes ('true'). Für Module vom Typ ``normal'' nicht wesentlich.
• [strict_subworkflow:]boolsches Flag, das identisch mit dem 'strict_subworkflow'-Flag des direkten Parent-Schrittes ist (siehe Rückgabe der 'head'-Funktion eines Parent-Moduls in ). Für Module vom Typ ``normal'' unwichtig.
• [parent_args:]Array, das Variablen enthält, die die Parent-Schritte über die 'head'-Funktion an die Module dieses Schrittes übergeben (siehe Rückgabe der 'head'-Funktion eines Parent-Moduls in ). Hier werden die für einen bestimmten Subworkflow-Durchlauf relevanten Daten, wie z.B. die Nummer der aktuellen Klausur, übergeben.

Spezielle Rückgaben sind nicht zu machen.

Prinzipiell kann jedes Modul, wenn es für einem Workflow-Schritt aufgerufen wird, jede in bis beschriebene Funktion aufrufen, die Informationen über den Status ihres Schrittes ermittelt. Bei Modulen vom Typ ``normal'' ist dies aber i.a. nicht notwendig, da sie sich nicht mit der Workflow-Steuerung befassen. Aber die Funktionen zum Zugriff auf temporäre Daten, wie z.B. 'wf_temp_data_get', 'wf_temp_data_set', sind auch dafür gedacht von normalen Modulen benutzt zu werden.

Wird ein Modul vom Typ 'normal' jedoch für eine Extrapage aufgerufen($control_args[isextrapage]='true'), so enthält $control_args nur die Parameter 'isextrapage' (hier gleich 'true'), step_nr (ist hier als Extrapagenummer aufzufassen) und step_name (als Name der Extrapage) (vgl. ). Auch sollte dann nicht versucht werden Workflow-Status des Schrittes $control_args[step_nr] zu ermitteln, da der Parameter 'step_nr' eine Extrapagenummer und nicht die Schrittnummer eines Workflow-Schrittes bezeichnet.

Darüberhinaus kann ein Modul vom Typ 'normal', wie auch jedes Modul anderen Typs, weitere Modulfunktionen enthalten, die die gesamte HTML-Seite selbst erzeugen, um mit $param[wf_step_position]=''Modulepage'' allein auf einer HTML-Seite dargestellt zu werden (siehe ).