Output API - Revision history

Devdocsbot: Protected "Output API": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

2022-06-14T03:18:23Z

Protected "Output API": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

← Older revision	Revision as of 03:18, 14 June 2022
(No difference)

Devdocsbot: Update migration status and path

2022-06-14T03:16:46Z

Update migration status and path

← Older revision		Revision as of 03:16, 14 June 2022
Line 1:		Line 1:
			{{Template:Migrated\|newDocId=/docs/apis/subsystems/output}}
	{{Template:Work in progress}}		{{Template:Work in progress}}

Mudrd8mz: Text replacement - "`" to ""`


2021-07-15T08:07:47Z
Text replacement - "<code (.*)>" to "<syntaxhighlight lang="$1">"

				
				
				
				
				
				← Older revision
				Revision as of 08:07, 15 July 2021
				
Line 165:
Line 165:



admin/tool/demo/templates/index_page.mustache admin/tool/demo/templates/index_page.mustache
<code xml> <syntaxhighlight lang="xml">
<div class="hero-unit">                                                                                                               <div class="hero-unit">                                                                                                              
   <h1>Heading</h1>                                                                                                                       <h1>Heading</h1>



Mudrd8mz: Text replacement - "" to ""

2021-07-14T13:34:58Z
Text replacement - "<code php>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:34, 14 July 2021
				
Line 11:
Line 11:
E.g.   E.g.  
/admin/tool/demo/index.php /admin/tool/demo/index.php
<code php> <syntaxhighlight lang="php">
<?php <?php
// Standard GPL and phpdocs // Standard GPL and phpdocs
Line 48:
Line 48:



Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).   Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).  
<code php> <syntaxhighlight lang="php">
           
// Set up the page. // Set up the page.
Line 67:
Line 67:
$PAGE also lets us load specific renderers for a plugin, or plugin and subtype. We will cover renderers in more detail next. $PAGE also lets us load specific renderers for a plugin, or plugin and subtype. We will cover renderers in more detail next.



<code php> <syntaxhighlight lang="php">
$output = $PAGE->get_renderer('tool_demo'); $output = $PAGE->get_renderer('tool_demo');



Line 77:
Line 77:






<code php> <syntaxhighlight lang="php">
echo $output->header(); echo $output->header();
echo $output->heading($pagetitle); echo $output->heading($pagetitle);
Line 84:
Line 84:
This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use  headings. This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use  headings.



<code php> <syntaxhighlight lang="php">
$renderable = new \tool_demo\output\index_page('Some text'); $renderable = new \tool_demo\output\index_page('Some text');
echo $output->render($renderable); echo $output->render($renderable);
Line 91:
Line 91:
This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.   This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.  



<code php> <syntaxhighlight lang="php">
echo $output->footer(); echo $output->footer();
</syntaxhighlight> </syntaxhighlight>
Line 100:
Line 100:



/admin/tool/demo/classes/output/index_page.php /admin/tool/demo/classes/output/index_page.php
<code php> <syntaxhighlight lang="php">
<?php <?php
// Standard GPL and phpdocs // Standard GPL and phpdocs
Line 136:
Line 136:



admin/tool/demo/classes/output/renderer.php admin/tool/demo/classes/output/renderer.php
<code php> <syntaxhighlight lang="php">
<?php <?php
// Standard GPL and phpdocs // Standard GPL and phpdocs



Mudrd8mz: Text replacement - "

" to ""

2021-07-14T13:05:36Z
Text replacement - "<code php>  " to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:05, 14 July 2021
				
Line 40:
Line 40:



Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages. Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages.
<code php> <syntaxhighlight lang="php">// Standard GPL and phpdocs
  
// Standard GPL and phpdocs 
require_once(__DIR__ . '/../../../config.php'); require_once(__DIR__ . '/../../../config.php');
require_once($CFG->libdir.'/adminlib.php'); require_once($CFG->libdir.'/adminlib.php');



Mudrd8mz: Text replacement - "" to ""
2021-07-14T13:02:26Z
Text replacement - "</code>" to "</syntaxhighlight>"

				
				
				
				
				
				← Older revision
				Revision as of 13:02, 14 July 2021
				
Line 37:
Line 37:
echo $output->footer(); echo $output->footer();



</code> </syntaxhighlight>



Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages. Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages.
Line 47:
Line 47:



admin_externalpage_setup('tooldemo'); admin_externalpage_setup('tooldemo');
</code> </syntaxhighlight>



Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).   Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).  
Line 59:
Line 59:
$PAGE->set_title($title); $PAGE->set_title($title);
$PAGE->set_heading($title); $PAGE->set_heading($title);
</code> </syntaxhighlight>



What is $PAGE and where did it come from ? What is $PAGE and where did it come from ?
Line 72:
Line 72:
$output = $PAGE->get_renderer('tool_demo'); $output = $PAGE->get_renderer('tool_demo');



</code> </syntaxhighlight>



This gets an instance of the plugin_renderer_base class that we use to create all output for our page. Themers can subclass this renderer to override specific render methods in order to customise Moodle's output. See [[Output_renderers]] for more information, and [[Overriding_a_renderer]] for information about how themers can customise a renderer.   This gets an instance of the plugin_renderer_base class that we use to create all output for our page. Themers can subclass this renderer to override specific render methods in order to customise Moodle's output. See [[Output_renderers]] for more information, and [[Overriding_a_renderer]] for information about how themers can customise a renderer.  
Line 82:
Line 82:
echo $output->header(); echo $output->header();
echo $output->heading($pagetitle); echo $output->heading($pagetitle);
</code> </syntaxhighlight>



This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use  headings. This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use  headings.
Line 89:
Line 89:
$renderable = new \tool_demo\output\index_page('Some text'); $renderable = new \tool_demo\output\index_page('Some text');
echo $output->render($renderable); echo $output->render($renderable);
</code> </syntaxhighlight>



This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.   This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.  
Line 95:
Line 95:
<code php> <code php>
echo $output->footer(); echo $output->footer();
</code> </syntaxhighlight>



This prints the HTML for the bottom of the page. It is very important because it also prints out things that were added to the page_requirements_manager and need to be printed in the footer. Things like javascript includes, navigation tree setup, closing open containers tags etc. The reason all javascripts are added to the footer of the page is for performance. If you add javascript includes to the top of the page, or inline with the content the browser must stop and execute the javascript before it can render the page. See https://developers.google.com/speed/docs/insights/BlockingJS for more information. This prints the HTML for the bottom of the page. It is very important because it also prints out things that were added to the page_requirements_manager and need to be printed in the footer. Things like javascript includes, navigation tree setup, closing open containers tags etc. The reason all javascripts are added to the footer of the page is for performance. If you add javascript includes to the top of the page, or inline with the content the browser must stop and execute the javascript before it can render the page. See https://developers.google.com/speed/docs/insights/BlockingJS for more information.
Line 131:
Line 131:
     }      }
}           }          
</code> </syntaxhighlight>



This class implements the renderable interface, which has no methods, and the templatable interface, which means that this class could be rendered with a template, so it must implement the "export_for_template" method. So in this example, the class accepts data via it's constructor, and stores that data in class variables. It does nothing else fancy with the data in this example (but it could). Note that the export_for_template function should only return simple types (arrays, stdClass, bool, int, float, string). This class implements the renderable interface, which has no methods, and the templatable interface, which means that this class could be rendered with a template, so it must implement the "export_for_template" method. So in this example, the class accepts data via it's constructor, and stores that data in class variables. It does nothing else fancy with the data in this example (but it could). Note that the export_for_template function should only return simple types (arrays, stdClass, bool, int, float, string).
Line 160:
Line 160:
     }                  }            
} }
</code> </syntaxhighlight>



The renderer exists to provide render_x methods for all renderables used in the plugin. A theme designer can provide a custom version of this renderer that changes the behaviour of any of the render methods and so to customize their theme. In this example, the render method for the index page (render_index_page) does 2 things. It asks the renderable to export it's data so that it is suitable for passing as the context to a template, and then renders a specific template with this context. A themer could either manipulate the data in the render method (e.g. removing menu entries), or change the template (change the generated html) to customize the output.   The renderer exists to provide render_x methods for all renderables used in the plugin. A theme designer can provide a custom version of this renderer that changes the behaviour of any of the render methods and so to customize their theme. In this example, the render method for the index page (render_index_page) does 2 things. It asks the renderable to export it's data so that it is suitable for passing as the context to a template, and then renders a specific template with this context. A themer could either manipulate the data in the render method (e.g. removing menu entries), or change the template (change the generated html) to customize the output.  
Line 172:
Line 172:
   <p>{{sometext}}</p>                                                                                                                    <p>{{sometext}}</p>                                                                                                                
</div>   </div>  
</code> </syntaxhighlight>



This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]]. This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]].



Michael-milette at 19:59, 27 April 2020
2020-04-27T19:59:13Z


				
				
				
				
				
				← Older revision
				Revision as of 19:59, 27 April 2020
				
Line 175:
Line 175:



This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]]. This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]].
==See also==

* [[Output_functions]]





Marcojones at 11:26, 11 December 2018
2018-12-11T11:26:48Z


				
				
				
				
				
				← Older revision
				Revision as of 11:26, 11 December 2018
				
Line 137:
Line 137:
Now lets look at the renderer for this plugin. Now lets look at the renderer for this plugin.



tool/admin/demo/classes/output/renderer.php admin/tool/demo/classes/output/renderer.php
<code php> <code php>
<?php <?php





Sfsharapov: Added compatibility notice for 3.x versions
2018-01-28T17:02:51Z
Added compatibility notice for 3.x versions

				
				
				
				
				
				← Older revision
				Revision as of 17:02, 28 January 2018
				
Line 4:
Line 4:



This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.   This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.  

It will work with Moodle 3.x, if you additionally follow instructions given [https://moodle.org/mod/forum/discuss.php?d=322196 here] (creating version.php file).



Lets start with building a page that is part of an admin tool. Lets start with building a page that is part of an admin tool.



Fpataleta at 06:23, 13 November 2017
2017-11-13T06:23:57Z


				
				
				
				
				
				← Older revision
				Revision as of 06:23, 13 November 2017
				
Line 2:
Line 2:



{{ Moodle 2.9 }} {{ Moodle 2.9 }}

See [[ Output Components ]] for (much) older information on the using output components in previous versions of Moodle. 



This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.   This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.

← Older revision		Revision as of 08:07, 15 July 2021
Line 165:		Line 165:

	admin/tool/demo/templates/index_page.mustache		admin/tool/demo/templates/index_page.mustache
	<~~code~~ xml>		<syntaxhighlight lang="xml">
	<div class="hero-unit">		<div class="hero-unit">
	<h1>Heading</h1>		<h1>Heading</h1>

← Older revision		Revision as of 13:34, 14 July 2021
Line 11:		Line 11:
	E.g.		E.g.
	/admin/tool/demo/index.php		/admin/tool/demo/index.php
	<~~code~~ php>		<syntaxhighlight lang="php">
	<?php		<?php
	// Standard GPL and phpdocs		// Standard GPL and phpdocs
Line 48:		Line 48:

	Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).		Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).
	<~~code~~ php>		<syntaxhighlight lang="php">

	// Set up the page.		// Set up the page.
Line 67:		Line 67:
	$PAGE also lets us load specific renderers for a plugin, or plugin and subtype. We will cover renderers in more detail next.		$PAGE also lets us load specific renderers for a plugin, or plugin and subtype. We will cover renderers in more detail next.

	<~~code~~ php>		<syntaxhighlight lang="php">
	$output = $PAGE->get_renderer('tool_demo');		$output = $PAGE->get_renderer('tool_demo');

Line 77:		Line 77:


	<~~code~~ php>		<syntaxhighlight lang="php">
	echo $output->header();		echo $output->header();
	echo $output->heading($pagetitle);		echo $output->heading($pagetitle);
Line 84:		Line 84:
	This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use headings.		This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use headings.

	<~~code~~ php>		<syntaxhighlight lang="php">
	$renderable = new \tool_demo\output\index_page('Some text');		$renderable = new \tool_demo\output\index_page('Some text');
	echo $output->render($renderable);		echo $output->render($renderable);
Line 91:		Line 91:
	This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.		This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.

	<~~code~~ php>		<syntaxhighlight lang="php">
	echo $output->footer();		echo $output->footer();
	</syntaxhighlight>		</syntaxhighlight>
Line 100:		Line 100:

	/admin/tool/demo/classes/output/index_page.php		/admin/tool/demo/classes/output/index_page.php
	<~~code~~ php>		<syntaxhighlight lang="php">
	<?php		<?php
	// Standard GPL and phpdocs		// Standard GPL and phpdocs
Line 136:		Line 136:

	admin/tool/demo/classes/output/renderer.php		admin/tool/demo/classes/output/renderer.php
	<~~code~~ php>		<syntaxhighlight lang="php">
	<?php		<?php
	// Standard GPL and phpdocs		// Standard GPL and phpdocs

← Older revision		Revision as of 13:05, 14 July 2021
Line 40:		Line 40:

	Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages.		Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages.
	<~~code~~ php>		<syntaxhighlight lang="php">// Standard GPL and phpdocs

	// Standard GPL and phpdocs
	require_once(__DIR__ . '/../../../config.php');		require_once(__DIR__ . '/../../../config.php');
	require_once($CFG->libdir.'/adminlib.php');		require_once($CFG->libdir.'/adminlib.php');

← Older revision		Revision as of 13:02, 14 July 2021
Line 37:		Line 37:
	echo $output->footer();		echo $output->footer();

	</~~code~~>		</syntaxhighlight>

	Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages.		Explaining this demo step by step we have firstly the standard config and includes, plus the admin_externalpage_setup('tooldemo') which calls require_login and performs permissions checks for admin pages.
Line 47:		Line 47:

	admin_externalpage_setup('tooldemo');		admin_externalpage_setup('tooldemo');
	</~~code~~>		</syntaxhighlight>

	Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).		Then we load the title of the page from a lang string (see [[String_API]] ). We use this string to set some $PAGE properties (url title and heading).
Line 59:		Line 59:
	$PAGE->set_title($title);		$PAGE->set_title($title);
	$PAGE->set_heading($title);		$PAGE->set_heading($title);
	</~~code~~>		</syntaxhighlight>

	What is $PAGE and where did it come from ?		What is $PAGE and where did it come from ?
Line 72:		Line 72:
	$output = $PAGE->get_renderer('tool_demo');		$output = $PAGE->get_renderer('tool_demo');

	</~~code~~>		</syntaxhighlight>

	This gets an instance of the plugin_renderer_base class that we use to create all output for our page. Themers can subclass this renderer to override specific render methods in order to customise Moodle's output. See [[Output_renderers]] for more information, and [[Overriding_a_renderer]] for information about how themers can customise a renderer.		This gets an instance of the plugin_renderer_base class that we use to create all output for our page. Themers can subclass this renderer to override specific render methods in order to customise Moodle's output. See [[Output_renderers]] for more information, and [[Overriding_a_renderer]] for information about how themers can customise a renderer.
Line 82:		Line 82:
	echo $output->header();		echo $output->header();
	echo $output->heading($pagetitle);		echo $output->heading($pagetitle);
	</~~code~~>		</syntaxhighlight>

	This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use headings.		This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See [[HTML_Guidelines]] for more information on how and where to use headings.
Line 89:		Line 89:
	$renderable = new \tool_demo\output\index_page('Some text');		$renderable = new \tool_demo\output\index_page('Some text');
	echo $output->render($renderable);		echo $output->render($renderable);
	</~~code~~>		</syntaxhighlight>

	This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.		This is the most interesting part of our page. We are creating a renderable and telling our renderer to render it. The renderable is usually more complex than this, it should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance and the results should be passed as data to the renderable. The renderable then just takes that data and returns a HTML representation of it.
Line 95:		Line 95:
	<code php>		<code php>
	echo $output->footer();		echo $output->footer();
	</~~code~~>		</syntaxhighlight>

	This prints the HTML for the bottom of the page. It is very important because it also prints out things that were added to the page_requirements_manager and need to be printed in the footer. Things like javascript includes, navigation tree setup, closing open containers tags etc. The reason all javascripts are added to the footer of the page is for performance. If you add javascript includes to the top of the page, or inline with the content the browser must stop and execute the javascript before it can render the page. See https://developers.google.com/speed/docs/insights/BlockingJS for more information.		This prints the HTML for the bottom of the page. It is very important because it also prints out things that were added to the page_requirements_manager and need to be printed in the footer. Things like javascript includes, navigation tree setup, closing open containers tags etc. The reason all javascripts are added to the footer of the page is for performance. If you add javascript includes to the top of the page, or inline with the content the browser must stop and execute the javascript before it can render the page. See https://developers.google.com/speed/docs/insights/BlockingJS for more information.
Line 131:		Line 131:
	}		}
	}		}
	</~~code~~>		</syntaxhighlight>

	This class implements the renderable interface, which has no methods, and the templatable interface, which means that this class could be rendered with a template, so it must implement the "export_for_template" method. So in this example, the class accepts data via it's constructor, and stores that data in class variables. It does nothing else fancy with the data in this example (but it could). Note that the export_for_template function should only return simple types (arrays, stdClass, bool, int, float, string).		This class implements the renderable interface, which has no methods, and the templatable interface, which means that this class could be rendered with a template, so it must implement the "export_for_template" method. So in this example, the class accepts data via it's constructor, and stores that data in class variables. It does nothing else fancy with the data in this example (but it could). Note that the export_for_template function should only return simple types (arrays, stdClass, bool, int, float, string).
Line 160:		Line 160:
	}		}
	}		}
	</~~code~~>		</syntaxhighlight>

	The renderer exists to provide render_x methods for all renderables used in the plugin. A theme designer can provide a custom version of this renderer that changes the behaviour of any of the render methods and so to customize their theme. In this example, the render method for the index page (render_index_page) does 2 things. It asks the renderable to export it's data so that it is suitable for passing as the context to a template, and then renders a specific template with this context. A themer could either manipulate the data in the render method (e.g. removing menu entries), or change the template (change the generated html) to customize the output.		The renderer exists to provide render_x methods for all renderables used in the plugin. A theme designer can provide a custom version of this renderer that changes the behaviour of any of the render methods and so to customize their theme. In this example, the render method for the index page (render_index_page) does 2 things. It asks the renderable to export it's data so that it is suitable for passing as the context to a template, and then renders a specific template with this context. A themer could either manipulate the data in the render method (e.g. removing menu entries), or change the template (change the generated html) to customize the output.
Line 172:		Line 172:
	<p>{{sometext}}</p>		<p>{{sometext}}</p>
	</div>		</div>
	</~~code~~>		</syntaxhighlight>

	This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]].		This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]].

← Older revision		Revision as of 19:59, 27 April 2020
Line 175:		Line 175:

	This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]].		This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see [[Templates]].
			==See also==

			* [[Output_functions]]

← Older revision		Revision as of 11:26, 11 December 2018
Line 137:		Line 137:
	Now lets look at the renderer for this plugin.		Now lets look at the renderer for this plugin.

	tool~~/admin~~/demo/classes/output/renderer.php		admin/tool/demo/classes/output/renderer.php
	<code php>		<code php>
	<?php		<?php

← Older revision		Revision as of 17:02, 28 January 2018
Line 4:		Line 4:

	This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.		This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.

			It will work with Moodle 3.x, if you additionally follow instructions given [https://moodle.org/mod/forum/discuss.php?d=322196 here] (creating version.php file).

	Lets start with building a page that is part of an admin tool.		Lets start with building a page that is part of an admin tool.

← Older revision		Revision as of 06:23, 13 November 2017
Line 2:		Line 2:

	{{ Moodle 2.9 }}		{{ Moodle 2.9 }}

	~~See [[ Output Components ]] for (much) older information on the using output components in previous versions of Moodle.~~

	This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.		This page is a fresh attempt to explain how renderers, renderables, themes and templates all work together for Moodle 2.9.

Output API - Revision history

Devdocsbot: Protected "Output API": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

Devdocsbot: Update migration status and path

Mudrd8mz: Text replacement - "" to ""

Mudrd8mz: Text replacement - "" to ""

Mudrd8mz: Text replacement - " " to ""

Mudrd8mz: Text replacement - "" to ""

Michael-milette at 19:59, 27 April 2020

Marcojones at 11:26, 11 December 2018

Sfsharapov: Added compatibility notice for 3.x versions

Fpataleta at 06:23, 13 November 2017

Mudrd8mz: Text replacement - "`" to ""`

Mudrd8mz: Text replacement - "`" to ""`

Mudrd8mz: Text replacement - "`" to ""`

`Mudrd8mz: Text replacement - "`" to ""