Gruntle Enterprise

in the [previous](/iris/blog/2006/jul/19/database-template-loader/) article, i outlined some of the hurdles i encountered while developing the basic infrastructure for a template loader that renders templates stored in a database. once the templates were rendering properly and the cascading effects of how the template loaders work or should work (see the section on the admin site), another problem arose when i tried to use templatetags within the templates to include page parts and snippets, which might include django template code and variables made available to the templates. for some reason, the data was displayed as "text" and all django related code was not rendered but displayed as code source. i assumed that since the parent template, we'll call it base.html, was loaded and rendered via the custom template loader that i created, the child bits (e.g. header, footer, sidebar) would be rendered properly as well without having to do much aside from retrieving the data from the database and spitting it out. turns out, that you must tell your templatetag to spit out rendered data, processed by the template class via the RequestContext method. and it must be RequestContext and not just context, since with RequestContext you also get context processors like auth and any custom ones you might have created. to do this as default, you must include django.core.context_processors.request in your list of TEMPLATE_CONTEXT_PROCESSORS. so the relevant code for my templatetag:

        snippet = Snippet.objects.get(name=self.name)
        t = template.Template(snippet.content)
        context[self.varname] = t.render(context)

will render any template code and variables properly and spit out text/html but also provides access to essential template objects via the auth context processor. and because we have some sitewide variables declared in a custom context processor that are then available in the templates, we can also make use of them as well when called from a templatetag that draws its data from a database. sweet. one side note about the {% load templatetag %} manoeuvre, because django templates are not designed to inherit the load values from parents, you have to include the load command in each page part and snippet, which is kind of a drag but that's how django works. as the authors state in the [documentation](http://www.djangoproject.com/documentation/templates/): "When you load a custom tag or filter library, the tags/filters are only made available to the current template -- not any parent or child templates along the template-inheritance path. "For example, if a template foo.html has {% load comments %}, a child template (e.g., one that has {% extends "foo.html" %}) will not have access to the comments template tags and filters. The child template is responsible for its own {% load comments %}. "This is a feature for the sake of maintainability and sanity." 0 Comments, 0 trackbacks (Trackback URL)