Variables and functions available to templates¶
The following global variables and functions are available to all CKAN templates in their top-level namespace:
Note
In addition to the global variables listed below, each template also has access to variables from a few other sources:
Any extra variables explicitly passed into a template by the controller that rendered the template will also be available to that template, in its top-level namespace. Any variables explicitly added to the template context variable c will also be available to the template as attributes of c.
To see which additional global variables and context attributes are available to a given template, use CKAN’s debug footer.
Any variables explicitly passed into a template snippet in the calling {% snippet %} tag will be available to the snippet in its top-level namespace. To see these variables, use the debug footer.
Jinja2 also makes a number of filters, tests and functions available in each template’s global namespace. For a list of these, see the Jinja2 docs.
- tmpl_context¶
The Pylons template context object, a thread-safe object that the application can store request-specific variables against without the variables associated with one HTTP request getting confused with variables from another request.
tmpl_context is usually abbreviated to c (an alias).
Using c in CKAN is discouraged, use template helper functions instead. See Don’t use c.
c is not available to snippets.
- c¶
An alias for tmpl_context.
- app_globals¶
The Pylons App Globals object, an instance of the ckan.lib.app_globals.Globals class. The application can store request-independent variables against the app_globals object. Variables stored against app_globals are shared between all HTTP requests.
- g¶
An alias for app_globals.
- h¶
CKAN’s template helper functions, plus any custom template helper functions provided by any extensions.
- request¶
The Pylons Request object, contains information about the HTTP request that is currently being responded to, including the request headers and body, URL parameters, the requested URL, etc.
- response¶
The Pylons Response object, contains information about the HTTP response that is currently being prepared to be sent back to the user, including the HTTP status code, headers, cookies, etc.
- session¶
The Beaker session object, which contains information stored in the user’s currently active session cookie.
- _()¶
The pylons.i18n.translation.ugettext(value) function:
Mark a string for translation. Returns the localized unicode string of value.
Mark a string to be localized as follows:
_('This should be in lots of languages')
- N_()¶
The pylons.i18n.translation.gettext_noop(value) function:
Mark a string for translation without translating it. Returns value.
Used for global strings, e.g.:
foo = N_('Hello') class Bar: def __init__(self): self.local_foo = _(foo) h.set_lang('fr') assert Bar().local_foo == 'Bonjour' h.set_lang('es') assert Bar().local_foo == 'Hola' assert foo == 'Hello'
- ungettext()¶
The pylons.i18n.translation.ungettext(singular, plural, n) function:
Mark a string for translation. Returns the localized unicode string of the pluralized value.
This does a plural-forms lookup of a message id. singular is used as the message id for purposes of lookup in the catalog, while n is used to determine which plural form to use. The returned message is a Unicode string.
Mark a string to be localized as follows:
ungettext('There is %(num)d file here', 'There are %(num)d files here', n) % {'num': n}
- translator¶
An instance of the gettext.NullTranslations class. This is for internal use only, templates shouldn’t need to use this.
- class actions¶
The ckan.model.authz.Action class.
Todo
Remove this? Doesn’t appear to be used and doesn’t look like something we want.