Docs:Operational Overview
A rough overview of the internal operation of the Course Processor is given here. Some aspects of the system are glossed over - in particular, the complexities of the plugin loading system are skipped over entirely - but it should be enough to gain an understanding of the overall operation of the system.
The course processor software is split into roughly four major pieces: the core code; input handler plugins; output handler plugins; and reference handler plugins.
The core code - largely contained within the processor.pl script - coordinates the operation of the processor, loads the plugins that do the processing work, and invokes the input and output handlers on the course data as needed.
Which input handlers are used is determined automagically by inspecting the source data for the course. The core code asks each input handler whether it understands the source data, and whether it is capable of processing the source data into the standard intermediate format. If the input handler indicates that it knows what to do with the data, it will be run on the source data. This means that you do not need to tell the course processor which input handler plugins it should use on the source data as it can determine that for itself. If none of the input handlers can run on the course data then the processor will exit with an error. If this happens, you need to check that the necessary input handler plugins installed, the correct course data directory has been specified, and the data is in the correct format.
Once all of the input handler plugins have inspected the source, and possibly done work on it, the output handler plugin is invoked to do its work. Unlike the input handler plugins, it is generally necessary to specify which output handler plugin should be used: this allows the processor to be used to generate a variety of output formats by running it with different output handlers selected. Output hander plugins take the intermediate format data and perform a range of operations on it to create the final course data. For example, the HTML output handler takes the intermediate format data, processes any special tags in the data, and writes out the course content via a template engine to form a completed course.
The reference handler plugins are not invoked directly by the core code but rather by the output handler plugins: during processing of the intermediate data generated by the input plugins, the output handler does a number of special tag substitutions. One of these allows references to be included in the course data and, when one is encountered, the output handler passes processing of the reference to a reference handler selected by the user. This allows the generated references to be presented in a number of different styles depending on the reference handler selected.
The diagram to the right illustrates the operation of the processor when the source 'Course data' contains HTML files (either authored directly, or generated by exporting data from the wiki using wiki2course.pl). The course processor passes the data through the HTMLInputHandler to create the intermediate format data, and then the HTMLOutputHandler takes the intermediate format data, the framework data, and the template files and generates the course CBT.
| |||||||||||||||||||||||||||||||