This section describes a little bit about the objects and built-in functions that are available in templates.
The Context is the central object that is created when a template is first executed, and is responsible for handling all communication with the outside world. This includes two major components, one of which is the output buffer, which is a file-like object such as Python’s StringIO or similar, and the other a dictionary of variables that can be freely referenced within a template; this dictionary is a combination of the arguments sent to the render() function and some built-in variables provided by Mako’s runtime environment.
The buffer is stored within the Context, and writing to it is achieved by calling Context.write(). You usually don’t need to care about this as all text within a template, as well as all expressions provided by ${}, automatically send everything to this method. The cases you might want to be aware of its existence are if you are dealing with various filtering/buffering scenarios, which are described in Filtering and Buffering, or if you want to programmatically send content to the output stream, such as within a <% %> block.
<%
context.write("some programmatic text")
%>
The actual buffer may or may not be the original buffer sent to the Context object, as various filtering/caching scenarios may “push” a new buffer onto the context’s underlying buffer stack. For this reason, just stick with Context.write() and content will always go to the topmost buffer.
When your template is compiled into a Python module, the body content is enclosed within a Python function called render_body. Other top-level defs defined in the template are defined within their own function bodies which are named after the def’s name with the prefix render_ (i.e. render_mydef). One of the first things that happens within these functions is that all variable names that are referenced within the function which are not defined in some other way (i.e. such as via assignment, module level imports, etc.) are pulled from the Context object’s dictionary of variables. This is how you’re able to freely reference variable names in a template which automatically correspond to what was passed into the current Context.
% if someval is UNDEFINED: someval is: no value % else: someval is: ${someval} % endif
Another facet of the Context is that its dictionary of variables is immutable. Whatever is set when render() is called is what stays. Of course, since its Python, you can hack around this and change values in the context’s internal dictionary, but this will probably will not work as well as you’d think. The reason for this is that Mako in many cases creates copies of the Context object, which get sent to various elements of the template and inheriting templates used in an execution. So changing the value in your local Context will not necessarily make that value available in other parts of the template’s execution. Examples of where Mako creates copies of the Context include within top-level def calls from the main body of the template (the context is used to propagate locally assigned variables into the scope of defs; since in the template’s body they appear as inlined functions, Mako tries to make them act that way), and within an inheritance chain (each template in an inheritance chain has a different notion of parent and next, which are all stored in unique Context instances).
So what if I want to set values that are global to everyone within a template request? - All you have to do is provide a dictionary to your Context when the template first runs, and everyone can just get/set variables from that. Lets say its called attributes.
Running the template looks like:
output = template.render(attributes={})
Within a template, just reference the dictionary:
<%
attributes['foo'] = 'bar'
%>
'foo' attribute is: ${attributes['foo']}
Why can’t “attributes” be a built-in feature of the Context? - This is an area where Mako is trying to make as few decisions about your application as it possibly can. Perhaps you don’t want your templates to use this technique of assigning and sharing data, or perhaps you have a different notion of the names and kinds of data structures that should be passed around. Once again Mako would rather ask the user to be explicit.
Significant members off of Context include:
${next.body(**context.kwargs)}
A one-stop shop for all the names Mako defines. Most of these names are instances of Namespace, which are described in the next section, Namespaces. Also, most of these names other than Context and UNDEFINED are also present within the Context itself.
Bases: object
Provides runtime namespace, output buffer, and various callstacks for templates.
See The Mako Runtime Environment for detail on the usage of
create a new Context with a copy of this Context‘s current state, updated with the given dictionary.
Return the TemplateLookup associated with this Context.
Return the current writer function
Bases: object
Represents an undefined value in a template.
All template modules have a constant value UNDEFINED present which is an instance of this object.