Renderer: Difference between revisions
(Created page with "A renderer works with Themes to display all of the output for any component of Moodle. This concept was introduced in Moodle 2.0 with the addition of $OUTPUT class and associate...") |
David Mudrak (talk | contribs) m (Text replacement - "</code>" to "</syntaxhighlight>") |
||
(6 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
'''Note:''' More specific information can be found at [[Output renderers]] and [[Overriding a renderer]] | |||
A renderer works with Themes to display all of the output for any component of Moodle. This concept was introduced in Moodle 2.0 with the addition of $OUTPUT class and associated /lib php files. Moodle core, and each component, should have a renderers. You can also create a renderer for a special purpose, for example mod_quiz\output\edit_renderer. The point of renderers is to allow themes to have complete control over the HTML that is generated, usign the technique of [[Overriding a renderer]]. | |||
Renderers should contains no logic other than what is required to generate the display, and should be compartmentalised into functional chunks. Each chunk should be responsible for producing a widget or control used within the component. This output will vary depending on the component. For example the forum will have a method for displaying a forum post, displaying a thread (which most likely calls the forum post method), and displaying a search form. | |||
These days, acutally generating the HTML should be done with a template. The job of the render is then just to pass the data to the template in the expected format. Older renderes do the HTML generation in PHP code. | |||
Note, inside a renderer you should never refer to the globals $OUTPUT or $PAGE. You should use $this->output and $this->page. Plugin renderers should use methods from the core renderer whenever appropriate to keep the UI consistent. For example the forum renderer should use $this->output->heading() if it wants a heading (thought templates are changing this a bit). | |||
==Example of calling a renderer== | |||
When you actually want to do some output, you need to get an instance of your class (or whatever subclass the theme wants to substitute). For example: | When you actually want to do some output, you need to get an instance of your class (or whatever subclass the theme wants to substitute). For example: | ||
< | <syntaxhighlight lang="php"> | ||
global $PAGE; // If necessary. | global $PAGE; // If necessary. | ||
$wsoutput = $PAGE | $wsoutput = $PAGE->get_renderer('mod_workshop'); | ||
echo $wsoutput->manual_allocation_interface($workshop, $allocationdata); | echo $wsoutput->manual_allocation_interface($workshop, $allocationdata); | ||
</ | </syntaxhighlight> | ||
The | The mod_workshop_renderer object will have access to a moodle_core_renderer available as $this->output. You should use this instead of global $OUTPUT, and you should use it. That is, boxes in the workshop should look like boxes elsewhere, so boxes in the workshop should be output with $this->output->box(). | ||
==See also== | ==See also== | ||
*[[Themes 2.0 overriding a renderer]] | |||
*[[Themes 2.0]] | * [[Themes 2.0 overriding a renderer]] | ||
*[[Themes 2.0 creating your first theme]] | * [[Themes 2.0]] | ||
* [[Themes 2.0 creating your first theme]] | |||
* [[Output API]] | |||
* [[Output functions]] | |||
* [[Output renderers]] | |||
* [[Overriding a renderer]] |
Latest revision as of 20:21, 14 July 2021
Note: More specific information can be found at Output renderers and Overriding a renderer
A renderer works with Themes to display all of the output for any component of Moodle. This concept was introduced in Moodle 2.0 with the addition of $OUTPUT class and associated /lib php files. Moodle core, and each component, should have a renderers. You can also create a renderer for a special purpose, for example mod_quiz\output\edit_renderer. The point of renderers is to allow themes to have complete control over the HTML that is generated, usign the technique of Overriding a renderer.
Renderers should contains no logic other than what is required to generate the display, and should be compartmentalised into functional chunks. Each chunk should be responsible for producing a widget or control used within the component. This output will vary depending on the component. For example the forum will have a method for displaying a forum post, displaying a thread (which most likely calls the forum post method), and displaying a search form.
These days, acutally generating the HTML should be done with a template. The job of the render is then just to pass the data to the template in the expected format. Older renderes do the HTML generation in PHP code.
Note, inside a renderer you should never refer to the globals $OUTPUT or $PAGE. You should use $this->output and $this->page. Plugin renderers should use methods from the core renderer whenever appropriate to keep the UI consistent. For example the forum renderer should use $this->output->heading() if it wants a heading (thought templates are changing this a bit).
Example of calling a renderer
When you actually want to do some output, you need to get an instance of your class (or whatever subclass the theme wants to substitute). For example:
global $PAGE; // If necessary.
$wsoutput = $PAGE->get_renderer('mod_workshop');
echo $wsoutput->manual_allocation_interface($workshop, $allocationdata);
The mod_workshop_renderer object will have access to a moodle_core_renderer available as $this->output. You should use this instead of global $OUTPUT, and you should use it. That is, boxes in the workshop should look like boxes elsewhere, so boxes in the workshop should be output with $this->output->box().