Renderer: Difference between revisions
Mark Johnson (talk | contribs) (Fixed example code based on what really happens in /mod/workshop/ pages) |
David Mudrak (talk | contribs) m (Text replacement - "</code>" to "</syntaxhighlight>") |
||
| (4 intermediate revisions by 3 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->get_renderer('mod_workshop'); | $wsoutput = $PAGE->get_renderer('mod_workshop'); | ||
echo $wsoutput->manual_allocation_interface($workshop, $allocationdata); | echo $wsoutput->manual_allocation_interface($workshop, $allocationdata); | ||
</ | </syntaxhighlight> | ||
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(). | 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().
