Output Rendering
Last updated
Last updated
Cement defines an , as well as the default that implements the interface as a placeholder but does not actually produce any output.
Cement often includes multiple handler implementations of an interface that may or may not have additional features or functionality than the interface requires. The documentation below only references usage based on the interface and default handler (not the full capabilities of an implementation).
Cement Extensions That Provide Output Handlers:
API References:
The following options under modify configuration handling:
Option
Description
output_handler
The handler that implements the output interface.
Cement applications do not need to use an output handler by any means. Most small applications can get away with simple print()
statements. However, anyone who has ever built a bigger application that produces a lot of output will know that this can get ugly very quickly in your code.
Using an output handler allows the developer to keep their logic clean, and offload the display of relevant data to an output handler, possibly by templates or other means (GUI?).
An output handler has a render()
function that takes a data dictionary to produce output. Some output handlers may also accept a template
or other parameters that define how output is rendered. This is easily accessible by the application object.
The above example uses the default dummy
output handler, therefore nothing is displayed on screen. That said, for an example we can use the JSonOutputHandler to see something happen:
While some output handlers only require the data
dictionary, others can utilize text templates to render formatted output to console.
~/.myapp/templates
~/.config/myapp/templates
/usr/lib/myapp/templates
Once a template is found, loading stops and the template is rendered.
Template directories are looked for in the most common places by default as defined by :
All interfaces in Cement can be overridden with your own implementation. This can be done either by sub-classing itself, or by sub-classing an existing extension's handlers in order to alter their functionality.