Fixed #23789 -- TemplateResponse handles context differently from render
This commit is contained in:
parent
006451f894
commit
b748a8bc67
|
@ -154,4 +154,7 @@ class TemplateResponse(SimpleTemplateResponse):
|
|||
"""
|
||||
if isinstance(context, Context):
|
||||
return context
|
||||
return RequestContext(self._request, context, current_app=self._current_app)
|
||||
context_instance = RequestContext(self._request, current_app=self._current_app)
|
||||
if context:
|
||||
context_instance.push(context)
|
||||
return context_instance
|
||||
|
|
|
@ -287,9 +287,10 @@ invoked immediately.
|
|||
Using TemplateResponse and SimpleTemplateResponse
|
||||
=================================================
|
||||
|
||||
A TemplateResponse object can be used anywhere that a normal
|
||||
HttpResponse can be used. It can also be used as an alternative to
|
||||
calling :func:`~django.shortcuts.render_to_response()`.
|
||||
A TemplateResponse object can be used anywhere that a normal HttpResponse can be
|
||||
used. It can also be used as an alternative to calling
|
||||
:func:`~django.shortcuts.render()` or
|
||||
:func:`~django.shortcuts.render_to_response()`.
|
||||
|
||||
For example, the following simple view returns a
|
||||
:class:`TemplateResponse()` with a simple template, and a context
|
||||
|
|
|
@ -640,6 +640,20 @@ run this query::
|
|||
the serialization framework, that means that ``dumpdata`` output will now
|
||||
contain the SRID value of geometry objects.
|
||||
|
||||
Priority of context processors for ``TemplateResponse`` brought in line with ``render``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :class:`~django.template.response.TemplateResponse` constructor is designed to be a
|
||||
drop-in replacement for the :func:`~django.shortcuts.render` function. However,
|
||||
it had a slight incompatibility, in that for ``TemplateResponse``, context data
|
||||
from the passed in context dictionary could be shadowed by context data returned
|
||||
from context processors, whereas for ``render`` it was the other way
|
||||
around. This was a bug, and the behaviour of ``render`` is more appropriate,
|
||||
since it allows the globally defined context processors to be overridden locally
|
||||
in the view. If you were relying on the fact context data in a
|
||||
``TemplateResponse`` could be overridden using a context processor, you will
|
||||
need to change your code.
|
||||
|
||||
Miscellaneous
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
@ -233,6 +233,12 @@ class TemplateResponseTest(TestCase):
|
|||
Context({'foo': 'bar'})).render()
|
||||
self.assertEqual(response.content, b'bar')
|
||||
|
||||
def test_context_processor_priority(self):
|
||||
# context processors should be overridden by passed-in context
|
||||
response = self._response('{{ foo }}{{ processors }}',
|
||||
{'processors': 'no'}).render()
|
||||
self.assertEqual(response.content, b'no')
|
||||
|
||||
def test_kwargs(self):
|
||||
response = self._response(content_type='application/json',
|
||||
status=504)
|
||||
|
|
Loading…
Reference in New Issue