#23789: TemplateResponse handles context/context processors differently from
'render' shortcut
-------------------------------------------+------------------------
Reporter: spookylukey | Owner: nobody
Type: Bug | Status: new
Component: Template system | Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------------+------------------------
The documentation for `TemplateResponse` states that `TemplateResponse`
can be used as an alternative to `render_to_response`. (In fact, it would
be better to point out that it is a closer equivalent to `render`).
https://docs.djangoproject.com/en/dev/ref/template-response/#using-
templateresponse-and-simpletemplateresponse
Similarly, the docs for `render` suggest that the `TemplateResponse`
constructor can be used as a drop in equivalent: "the constructor of
TemplateResponse offers the same level of convenience as render()"
https://docs.djangoproject.com/en/dev/topics/http/shortcuts/#render
There is a subtle but significant difference, however:
If a context processor returns a dictionary with a key that is the same as
one in the context dictionary passed in to the `TemplateResponse`
constructor, then the priority is different: `TemplateResponse` will
overwrite (or shadow) the passed in context dictionary using the data from
the context processors, while `render` does it the other way around.
In my opinion, the behaviour in `render` is much more useful: there are a
number of circumstances when I might use a context processor to define
some default global data for templates, but then I might want to override
that in a specific view.
There is value the other way around, of course: if a 3rd party app
provides puts some data into a context that you want to change by
configuring a context processor. However, the whole point of
`TemplateResponse` is to make it easy to make changes like that in other
ways - a simple view wrapper or middleware will allow you to do it. The
behaviour of `render` is also older and therefore much more likely to have
patterns established around it.
I'd like us fix `TemplateResponse` to be in line with `render`, as it
represents a significant gotcha if you transition from `render` to
`TemplateResponse`. (In one project I've had to fix it using a custom
`TemplateResponse` subclass, but it took me a good while to debug the
problem). This, of course, is a backwards incompatible change for the
case where someone was relying on the current behaviour. However, given
that we do not currently test or document the current behaviour of
`TemplateResponse` in this regard, and the docs suggest the opposite (you
can use the `TemplateResponse` constructor as a way to get the behaviour
of `render` but with a `TemplateResponse` instance returned instead of an
`HttpResponse`), I think we can easily argue that the current behaviour
of `TemplateResponse` is a bug that should be fixed.
I'll attach a patch that implements it for reference, which is very
simple. Note that apart from the new test I've added, there are no
failures in our test suite caused by the change in behaviour i.e. nothing
in Django itself depends on the current behaviour. Obviously I'll add a
backwards compatibility note if others agree with this change, and then
commit.
--
Ticket URL: <https://code.djangoproject.com/ticket/23789>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/054.43b0233e8c3bec2d69b47da889351b3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
