Common subplugin features

There are multiple functions that are available within the API for both trigger and steps. They mainly allow to manage settings that are specific to a subplugin instance. The following functions can be implemented within the lib.php of the subplugin:

instance_settings()

Each subplugin can define its own set of settings. For these, the class instance_setting can be used, which is defined using a name, a moodle parameter type, and a boolean indicating whether the setting should be editable for a running workflow. The lifecycle API cares for the storage of the settings values of each subplugin instance. These values can manually be accessed using the Settings Manager.

extend_add_instance_form_definition($mform)

In addition to the general definition of the settings the following two functions can be used to extend the forms used for adding and editing a subplugin instance. This function is called when the add/edit instance form of the subplugin is created. Thus, the $mform variable can be used to add form elements to the instance form. For instance:

    public function extend_add_instance_form_definition($mform) {
        $mform->addElement('duration', 'delay', get_string('delay', 'lifecycletrigger_startdatedelay'));
        $mform->addHelpButton('delay', 'delay', 'lifecycletrigger_startdatedelay');
    }

extend_add_instance_form_definition_after_data($mform, $settings)

While the extend_add_instance_form_definition function mimics the definition() function of a moodleform, this function mimics the definition_after_data() function of the moodleform. Thus, the function can be used to initialize the form after the form elements have been created.