From cc4effba0bf07fbcb4dcc0074af969e698b6cc75 Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Tue, 17 Feb 2015 22:49:59 +0100 Subject: [1.8.x] Set context.template instead of context.engine while rendering. This opens more possibilities, like accessing context.template.origin. It also follows the chain of objects instead of following a shortcut. Backport of 1bfcc95 from master --- docs/howto/custom-template-tags.txt | 22 ++++++++++++---------- docs/ref/templates/upgrading.txt | 4 ++-- 2 files changed, 14 insertions(+), 12 deletions(-) (limited to 'docs') diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt index d8fde58ffd..ca21e16549 100644 --- a/docs/howto/custom-template-tags.txt +++ b/docs/howto/custom-template-tags.txt @@ -772,10 +772,11 @@ Notes: * The ``render()`` method is where the work actually happens. * ``render()`` should generally fail silently, particularly in a production - environment. In some cases however, particularly if ``context.engine.debug`` - is ``True``, this method may raise an exception to make debugging easier. - For example, several core tags raise ``django.template.TemplateSyntaxError`` - if they receive the wrong number or type of arguments. + environment. In some cases however, particularly if + ``context.template.engine.debug`` is ``True``, this method may raise an + exception to make debugging easier. For example, several core tags raise + ``django.template.TemplateSyntaxError`` if they receive the wrong number or + type of arguments. Ultimately, this decoupling of compilation and rendering results in an efficient template system, because a template can render multiple contexts @@ -811,16 +812,17 @@ This is not a very common situation, but it's useful if you're rendering a template yourself. For example:: def render(self, context): - t = context.engine.get_template('small_fragment.html') + t = context.template.engine.get_template('small_fragment.html') return t.render(Context({'var': obj}, autoescape=context.autoescape)) .. versionchanged:: 1.8 - The ``engine`` attribute of ``Context`` objects was added in Django 1.8. - :meth:`context.engine.get_template ` - must be used instead of :func:`django.template.loader.get_template` - because the latter now returns a wrapper whose ``render`` method doesn't - accept a :class:`~django.template.Context`. + The ``template`` attribute of ``Context`` objects was added in Django 1.8. + :meth:`context.template.engine.get_template + ` must be used instead of + :func:`django.template.loader.get_template` because the latter now returns + a wrapper whose ``render`` method doesn't accept a + :class:`~django.template.Context`. If we had neglected to pass in the current ``context.autoescape`` value to our new ``Context`` in this example, the results would have *always* been diff --git a/docs/ref/templates/upgrading.txt b/docs/ref/templates/upgrading.txt index 98778c36ba..33057d36bd 100644 --- a/docs/ref/templates/upgrading.txt +++ b/docs/ref/templates/upgrading.txt @@ -162,7 +162,7 @@ instance in the ``render()`` method of a template tag, you can use the current You can write:: - template = context.engine.get_template('included.html') + template = context.template.engine.get_template('included.html') This will load the template with the current engine without triggering the multiple template engines machinery, which is usually the desired behavior. @@ -201,7 +201,7 @@ APIs. The multiple template engines machinery isn't involved here. Finally, if you have access to the current context, you can use the same trick as above:: - template = context.engine.from_string(template_code) + template = context.template.engine.from_string(template_code) ``Template()`` ============== -- cgit v1.3