Search moodle.org's
Developer Documentation
Developer Documentation
See Release Notes
Long Term Support Release
- Bug fixes for general core bugs in 4.1.x will end 13 November 2023 (12 months).
- Bug fixes for security issues in 4.1.x will end 10 November 2025 (36 months).
- PHP version: minimum PHP 7.4.0 Note: minimum PHP version has increased since Moodle 4.0. PHP 8.0.x is supported too.
(no description)
| Copyright: | 2010 onwards Eloy Lafuente (stronk7) {@link http://stronk7.com} |
| License: | http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later |
| File Size: | 194 lines (8 kb) |
| Included or required: | 0 times |
| Referenced: | 1 time |
| Includes or requires: | 0 files |
Defines 1 class
backup_optigroup_element:: (12 methods):
__construct()
set_condition()
get_condition_param()
get_condition_value()
condition_matches()
get_level()
process()
add_add_optigroup()
add_attributes()
get_new_attribute()
get_new_final_element()
set_parent()
Class: backup_optigroup_element - X-Ref
Instantiable class representing one optigroup element for conditional branchingObjects of this class are internally nested elements, so they support having both
final elements and children (more nested elements) and are able to have one source
and all the stuff supported by nested elements. Their main differences are:
- Support for conditional execution, using simple equality checks with outer values.
- Don't have representation in the hierarchy, so:
- Their level is the level of the parent of their enclosing optigroup.
- Act as one "path bridge" when looking for parent path values
- They don't support attributes
Their main use is to allow conditional branching, basically for optional submodules
like question types, assignment subtypes... where different subtrees of information
must be exported. It's correct to assume that each submodule will define its own
optigroup_element for backup purposes.
| __construct($name, $final_elements = null, $conditionparam = null, $conditionvalue = null) X-Ref |
| Constructor - instantiates one backup_optigroup_element param: string $name of the element param: array $final_elements this element will handle (optional, defaults to null) param: string $condition_param param (path) we are using as source for comparing (optional, defaults to null) param: string $condition_value value we are comparing to (optional, defaults to null) |
| set_condition($conditionparam, $conditionvalue) X-Ref |
| Sets the condition for this optigroup |
| get_condition_param() X-Ref |
| No description |
| get_condition_value() X-Ref |
| No description |
| condition_matches() X-Ref |
| Evaluate the condition, returning if matches (true) or no (false) |
| get_level() X-Ref |
| Return the level of this element, that will be, the level of the parent (doesn't consume level) (note this os only a "cosmetic" effect (to_string) as fact as the real responsible for this is the corresponding structure_processor for the final output. |
| process($processor) X-Ref |
| process one optigroup_element Note that this ONLY processes the final elements in order to get all them before processing any nested element. Pending nested elements are processed by the optigroup caller. |
| add_add_optigroup($optigroup) X-Ref |
| Adding optigroups is forbidden |
| add_attributes($attributes) X-Ref |
| Adding attributes is forbidden |
| get_new_attribute($name) X-Ref |
| Instantiating attributes is forbidden |
| get_new_final_element($name) X-Ref |
| Returns one instace of the @final_element class to work with when final_elements are added simply by name |
| set_parent($element) X-Ref |
| Set the parent of the optigroup_element and, at the same time, process the condition param |
