TemplateView does not support setting mime type, like views.generic.simple.direct_to_template did

[gwahl@…]

I use direct_to_template to serve my robots.txt, like this:

urlpatterns = patterns('',
    url('^robots.txt$', TemplateView.as_view(template_name='robots.txt', content_type='text/plain')),
...

In Django 1.5 this is no longer possible, because the function-based generic views are removed, and TemplateView does not have a mime/content type argument.

I think that a content_type argument should be added to TemplateView to add the same functionality that was in the function-based view. Patch to come.

[gwahl@…]

Patch: ​https://github.com/django/django/pull/426

[Claude Paroz]

Docs needed at least in ​https://docs.djangoproject.com/en/dev/ref/class-based-views/mixins-simple/#templateresponsemixin

[Aymeric Augustin]

The root cause is that TemplateView uses two sets of keyword arguments to render itself:

• **kwargs => they're merged in the context by get_context_data, and they can be passed in the call to as_view()
• **response_kwargs => they're used in render_to_response to instantiate the response class, but currently they can't be passed without defining a subclass, hence the problem.

---

HttpResponseBase takes two arguments: content_type and status (plus mimetype, a deprecated alias for content_type).

TemplateView implies status = 200: otherwise one would use a different class like RedirectView.

So, the only remaining argument accepted by all HttpResponseBase subclasses is content_type, and it makes some sense to special-case it.

[Gavin Wahl <gwahl@…>]

I added docs to the pull request.

[Baptiste Mispelon]

Would it make sense to also add a get_content_type method (that would default to just returning self.content_type)?

A lot of the other generic views implement this pattern and it's useful in some cases.

[Aymeric Augustin]

Replying to bmispelon:

Would it make sense to also add a get_content_type method (that would default to just returning self.content_type)?
A lot of the other generic views implement this pattern and it's useful in some cases.

The accessor pattern is useful when views may have a good reason to incrementally modify the return value -- eg. the template context.

I don't see an use case for get_content_type, and it can be added later on in a backwards-compatible way in the need arises.

[Aymeric Augustin <aymeric.augustin@…>]

In 23e319d7298c8b778181e85dd9b6cbed095f8147:

Fixed #19076 -- Added content_type attribute to TemplateView.

Thanks Gavin Wahl.

[Aymeric Augustin]

This is a "new feature" for the class-based generic views, but it's also a "fix for a regression" as 1.5 removes the function-based generic views, and the class-based generic views don't provide this feature (yet).

For this reason, I'm going to backport to 1.5, even though we've already released a RC1. A RC2 is planned. Jacob and Florian agreed on IRC.

[Aymeric Augustin <aymeric.augustin@…>]

In d5ad9d3dfe729f8b605965e131c787fae9f84377:

[1.5.x] Fixed #19076 -- Added content_type attribute to TemplateView.

Thanks Gavin Wahl.

Backport of 23e319d.

[Aymeric Augustin <aymeric.augustin@…>]

In c8c7cdc8f8f81b2f162db7acc8faaef0ece3b6ae:

Changed "versionadded" after the decision to backport.

Refs #19076.

[Aymeric Augustin <aymeric.augustin@…>]

In d5ad9d3dfe729f8b605965e131c787fae9f84377:

[1.5.x] Fixed #19076 -- Added content_type attribute to TemplateView.

Thanks Gavin Wahl.

Backport of 23e319d.