Kudos to Mark Nielsen for his initial work on this project. In his code,
Mark described the valuable logic of the conversion using a framework
mirroring plan/tasks/steps based architecture of the backup and restore.
My attempt to simplify it led to the current handlers-based
architecture.
Added write_xml() helper that writes the given tree-ish structure into
the current xml writer. Improved get_contextid() so that it can use
indices for searching data. Added set_stash() and get_stash() helper
methods.
These are David's changes of Mark's code that replace the
plan/tasks/steps infrastructure with a bit simpler one. The changes will
be described in the next commit that will actually finish the
conversion.
TODO: refactor backup/converter/moodle1/stepslib.php into conversion
handlers.
* Several base_converter methods made protected when there was no obvious
reason why they should be public (subject of eventual change still).
* The conversion chain now constructed in advance before any converter
class is instantiated, using Dijkstra's algorithm.
This is a final cleanup commit of fullname and shortname issue. All
places where these strings were detected yet have been replaced with
proper fullnamecourse or fullnameuser or some other context specific
string.
AMOS BEGIN
CPY [fullname,core],[outcomefullname,core_grades]
CPY [shortname,core],[outcomeshortname,core_grades]
CPY [name,core],[rolefullname,core_role]
CPY [shortname,core],[roleshortname,core_role]
AMOS END
after this change any restore_structure_step processor
method is able to instruct the dispatcher about to skip
any path below it. Until now, we were doing the checks on
each child processor method, but that was inneficient and
prone to errors (easy to miss the check in a child so some
orphaned piezes of restore may be causing mess here and there).
Once implemented, it's simlpy a matter of the parent deciding if
all its children must be processed or no. Easier for developers
and also small speed improvement because avoids unnecesary
dispatching/processing to happen.
Surely only will be used in parts of core, like in question_categories,
saving 50-60 sub processors (sub-paths) to be dispatched.
