Nur in End-Schritten kommen Module vom Typ 'end' (kurz End-Module) vor. Sie dienen der Deaktivierung ihres Subworkflows. In aller Regel sollten sie erst dann eine Deaktivierung zulassen, wenn ihre normalen Abhängigkeiten es erlauben.
End-Module müssen nur die Modulfunktion ``main'' (gleiche $control_args
wie beim Typ ``normal'', keine Rückgaben) enthalten. Darin können
sie, v.a. wenn alle ihre normalen Abhängigkeiten erfüllt sind, es
dem Benutzer gestatten ihren Subworkflow zu deaktivieren. Die Deaktivierung
wird am besten indirekt mit Global-Actions (z.b. über die Funktion
'wf_globalaction_form_element', siehe )
ausgelöst. Denn wenn ein End-Modul eines End-Schrittes seinen Subworkflow
selbst über die Funktion 'wf_subworkflow_close' sperrt, werden z.B.
in der HTML-Anzeige über dem End-Schritt von den 'head'-Funktionen
der indirekten Parent-Schritte noch veraltete Informationen (über
noch nicht geschlossenen Subworkflow) angezeigt. Der Status des Subworkflows
und des End-Schrittes selbst kann mit Funktionen wie 'wf_subworkflow_status',
'wf_step_status', etc. abgefragt werden. Insbesondere sollte auf
den Parameter $control_args[subworkflow_mode_old] geachtet
werden. Ist dieser glich 'true', sollte das Modul am besten gar nichts
tun, da es sich hier um die Bearbeitung eines abgeschlossenen Subworkflow-Durchlaufes
handelt.
End-Module können wie alle Module bei Bedarf über die 'wf_temp_data...'-Funktionen
(siehe ) zusätzliche, temporäre Informationen
verwalten. Sie können auch weitere Modulfunktionen zum Aufbau ganzer
HTML-Seiten durch eine einzige Modulfunktion ($param[wf_step_position]=''Modulpage'',
siehe
) enthalten.
Speziell ist zu End-Schritten zu sagen, dass das Workflow-System nie eine Änderung des 'erledigt'-Status eines End-Schrittes anbietet. D.h. wenn der Subworkflow eines End-Schrittes aktiv ist, so hat dieser stets den 'erledigt'-Status 'offen'.