Browse Source

Fixed #23789 -- TemplateResponse handles context differently from render

Luke Plant 10 years ago
parent
commit
b748a8bc67

+ 4 - 1
django/template/response.py

@@ -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

+ 4 - 3
docs/ref/template-response.txt

@@ -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

+ 14 - 0
docs/releases/1.8.txt

@@ -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
 ~~~~~~~~~~~~~
 

+ 6 - 0
tests/template_tests/test_response.py

@@ -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)