Django’s built-in class-based views provide a lot of functionality,\nbut some of it you may want to use separately. For instance, you may\nwant to write a view that renders a template to make the HTTP\nresponse, but you can’t use\nTemplateView; perhaps you need to\nrender a template only on POST, with GET doing something else\nentirely. While you could use\nTemplateResponse directly, this\nwill likely result in duplicate code.
For this reason, Django also provides a number of mixins that provide\nmore discrete functionality. Template rendering, for instance, is\nencapsulated in the\nTemplateResponseMixin. The Django\nreference documentation contains full documentation of all the\nmixins.
Two central mixins are provided that help in providing a consistent\ninterface to working with templates in class-based views.
\nTemplateResponseMixinEvery built in view which returns a\nTemplateResponse will call the\nrender_to_response()\nmethod that TemplateResponseMixin provides. Most of the time this\nwill be called for you (for instance, it is called by the get() method\nimplemented by both TemplateView and\nDetailView); similarly, it’s unlikely\nthat you’ll need to override it, although if you want your response to\nreturn something not rendered via a Django template then you’ll want to do\nit. For an example of this, see the JSONResponseMixin example.
render_to_response() itself calls\nget_template_names(),\nwhich by default will just look up\ntemplate_name on\nthe class-based view; two other mixins\n(SingleObjectTemplateResponseMixin\nand\nMultipleObjectTemplateResponseMixin)\noverride this to provide more flexible defaults when dealing with actual\nobjects.
ContextMixinEvery built in view which needs context data, such as for rendering a\ntemplate (including TemplateResponseMixin above), should call\nget_context_data() passing\nany data they want to ensure is in there as keyword arguments.\nget_context_data() returns a dictionary; in ContextMixin it\nsimply returns its keyword arguments, but it is common to override this to\nadd more members to the dictionary. You can also use the\nextra_context attribute.
Let’s look at how two of Django’s generic class-based views are built\nout of mixins providing discrete functionality. We’ll consider\nDetailView, which renders a\n«detail» view of an object, and\nListView, which will render a list\nof objects, typically from a queryset, and optionally paginate\nthem. This will introduce us to four mixins which between them provide\nuseful functionality when working with either a single Django object,\nor multiple objects.
There are also mixins involved in the generic edit views\n(FormView, and the model-specific\nviews CreateView,\nUpdateView and\nDeleteView), and in the\ndate-based generic views. These are\ncovered in the mixin reference\ndocumentation.
DetailView: working with a single Django objectLink to this heading#To show the detail of an object, we basically need to do two things:\nwe need to look up the object and then we need to make a\nTemplateResponse with a suitable template,\nand that object as context.
To get the object, DetailView\nrelies on SingleObjectMixin,\nwhich provides a\nget_object()\nmethod that figures out the object based on the URL of the request (it\nlooks for pk and slug keyword arguments as declared in the\nURLConf, and looks the object up either from the\nmodel attribute\non the view, or the\nqueryset\nattribute if that’s provided). SingleObjectMixin also overrides\nget_context_data(),\nwhich is used across all Django’s built in class-based views to supply\ncontext data for template renders.
To then make a TemplateResponse,\nDetailView uses\nSingleObjectTemplateResponseMixin,\nwhich extends TemplateResponseMixin,\noverriding\nget_template_names()\nas discussed above. It actually provides a fairly sophisticated set of options,\nbut the main one that most people are going to use is\n<app_label>/<model_name>_detail.html. The _detail part can be changed\nby setting\ntemplate_name_suffix\non a subclass to something else. (For instance, the generic edit\nviews use _form for create and update views, and\n_confirm_delete for delete views.)
ListView: working with many Django objectsLink to this heading#Lists of objects follow roughly the same pattern: we need a (possibly\npaginated) list of objects, typically a\nQuerySet, and then we need to make a\nTemplateResponse with a suitable template\nusing that list of objects.
To get the objects, ListView uses\nMultipleObjectMixin, which\nprovides both\nget_queryset()\nand\npaginate_queryset(). Unlike\nwith SingleObjectMixin, there’s no need\nto key off parts of the URL to figure out the queryset to work with, so the\ndefault just uses the\nqueryset or\nmodel attribute\non the view class. A common reason to override\nget_queryset()\nhere would be to dynamically vary the objects, such as depending on\nthe current user or to exclude posts in the future for a blog.
MultipleObjectMixin also overrides\nget_context_data() to\ninclude appropriate context variables for pagination (providing\ndummies if pagination is disabled). It relies on object_list being\npassed in as a keyword argument, which ListView arranges for\nit.
To make a TemplateResponse,\nListView then uses\nMultipleObjectTemplateResponseMixin;\nas with SingleObjectTemplateResponseMixin\nabove, this overrides get_template_names() to provide a range of\noptions,\nwith the most commonly-used being\n<app_label>/<model_name>_list.html, with the _list part again\nbeing taken from the\ntemplate_name_suffix\nattribute. (The date based generic views use suffixes such as _archive,\n_archive_year and so on to use different templates for the various\nspecialized date-based list views.)
Now we’ve seen how Django’s generic class-based views use the provided\nmixins, let’s look at other ways we can combine them. Of course we’re\nstill going to be combining them with either built-in class-based\nviews, or other generic class-based views, but there are a range of\nrarer problems you can solve than are provided for by Django out of\nthe box.
\n\nSingleObjectMixin with ViewLink to this heading#If we want to write a simple class-based view that responds only to\nPOST, we’ll subclass View and\nwrite a post() method in the subclass. However if we want our\nprocessing to work on a particular object, identified from the URL,\nwe’ll want the functionality provided by\nSingleObjectMixin.
We’ll demonstrate this with the Author model we used in the\ngeneric class-based views introduction.
from django.http import HttpResponseForbidden, HttpResponseRedirect\nfrom django.urls import reverse\nfrom django.views import View\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Author\n\nclass RecordInterest(SingleObjectMixin, View):\n """Records the current user's interest in an author."""\n model = Author\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n\n # Look up the author we're interested in.\n self.object = self.get_object()\n # Actually record interest somehow here!\n\n return HttpResponseRedirect(reverse('author-detail', kwargs={'pk': self.object.pk}))\nIn practice you’d probably want to record the interest in a key-value\nstore rather than in a relational database, so we’ve left that bit\nout. The only bit of the view that needs to worry about using\nSingleObjectMixin is where we want to\nlook up the author we’re interested in, which it just does with a simple call\nto self.get_object(). Everything else is taken care of for us by the\nmixin.
We can hook this into our URLs easily enough:
\nfrom django.urls import path\nfrom books.views import RecordInterest\n\nurlpatterns = [\n #...\n path('author/<int:pk>/interest/', RecordInterest.as_view(), name='author-interest'),\n]\nNote the pk named group, which\nget_object() uses\nto look up the Author instance. You could also use a slug, or\nany of the other features of\nSingleObjectMixin.
SingleObjectMixin with ListViewLink to this heading#ListView provides built-in\npagination, but you might want to paginate a list of objects that are\nall linked (by a foreign key) to another object. In our publishing\nexample, you might want to paginate through all the books by a\nparticular publisher.
One way to do this is to combine ListView with\nSingleObjectMixin, so that the queryset\nfor the paginated list of books can hang off the publisher found as the single\nobject. In order to do this, we need to have two different querysets:
Book queryset for use by ListViewSince we have access to the Publisher whose books we want to list, we\nsimply override get_queryset() and use the Publisher’s\nreverse foreign key manager.
Publisher queryset for use in get_object()We’ll rely on the default implementation of get_object() to fetch the\ncorrect Publisher object.\nHowever, we need to explicitly pass a queryset argument because\notherwise the default implementation of get_object() would call\nget_queryset() which we have overridden to return Book objects\ninstead of Publisher ones.
Now we can write a new PublisherDetail:
from django.views.generic import ListView\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Publisher\n\nclass PublisherDetail(SingleObjectMixin, ListView):\n paginate_by = 2\n template_name = "books/publisher_detail.html"\n\n def get(self, request, *args, **kwargs):\n self.object = self.get_object(queryset=Publisher.objects.all())\n return super().get(request, *args, **kwargs)\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context['publisher'] = self.object\n return context\n\n def get_queryset(self):\n return self.object.book_set.all()\nNotice how we set self.object within get() so we\ncan use it again later in get_context_data() and get_queryset().\nIf you don’t set template_name, the template will default to the normal\nListView choice, which in this case would be\n"books/book_list.html" because it’s a list of books;\nListView knows nothing about\nSingleObjectMixin, so it doesn’t have\nany clue this view is anything to do with a Publisher.
The paginate_by is deliberately small in the example so you don’t\nhave to create lots of books to see the pagination working! Here’s the\ntemplate you’d want to use:
{% extends "base.html" %}\n\n{% block content %}\n <h2>Publisher {{ publisher.name }}</h2>\n\n <ol>\n {% for book in page_obj %}\n <li>{{ book.title }}</li>\n {% endfor %}\n </ol>\n\n <div class="pagination">\n <span class="step-links">\n {% if page_obj.has_previous %}\n <a href="?page={{ page_obj.previous_page_number }}">previous</a>\n {% endif %}\n\n <span class="current">\n Page {{ page_obj.number }} of {{ paginator.num_pages }}.\n </span>\n\n {% if page_obj.has_next %}\n <a href="?page={{ page_obj.next_page_number }}">next</a>\n {% endif %}\n </span>\n </div>\n{% endblock %}\nGenerally you can use\nTemplateResponseMixin and\nSingleObjectMixin when you need\ntheir functionality. As shown above, with a bit of care you can even\ncombine SingleObjectMixin with\nListView. However things get\nincreasingly complex as you try to do so, and a good rule of thumb is:
To show what happens when you try to get more sophisticated, we show\nan example that sacrifices readability and maintainability when there\nis a simpler solution. First, let’s look at a naive attempt to combine\nDetailView with\nFormMixin to enable us to\nPOST a Django Form to the same URL as we’re\ndisplaying an object using DetailView.
FormMixin with DetailViewLink to this heading#Think back to our earlier example of using View and\nSingleObjectMixin together. We were\nrecording a user’s interest in a particular author; say now that we want to\nlet them leave a message saying why they like them. Again, let’s assume we’re\nnot going to store this in a relational database but instead in\nsomething more esoteric that we won’t worry about here.
At this point it’s natural to reach for a Form to\nencapsulate the information sent from the user’s browser to Django. Say also\nthat we’re heavily invested in REST, so we want to use the same URL for\ndisplaying the author as for capturing the message from the\nuser. Let’s rewrite our AuthorDetailView to do that.
We’ll keep the GET handling from DetailView, although\nwe’ll have to add a Form into the context data so we can\nrender it in the template. We’ll also want to pull in form processing\nfrom FormMixin, and write a bit of\ncode so that on POST the form gets called appropriately.
Our new AuthorDetail looks like this:
# CAUTION: you almost certainly do not want to do this.\n# It is provided as part of a discussion of problems you can\n# run into when combining different generic class-based view\n# functionality that is not designed to be used together.\n\nfrom django import forms\nfrom django.http import HttpResponseForbidden\nfrom django.urls import reverse\nfrom django.views.generic import DetailView\nfrom django.views.generic.edit import FormMixin\nfrom books.models import Author\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\nclass AuthorDetail(FormMixin, DetailView):\n model = Author\n form_class = AuthorInterestForm\n\n def get_success_url(self):\n return reverse('author-detail', kwargs={'pk': self.object.pk})\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n self.object = self.get_object()\n form = self.get_form()\n if form.is_valid():\n return self.form_valid(form)\n else:\n return self.form_invalid(form)\n\n def form_valid(self, form):\n # Here, we would record the user's interest using the message\n # passed in form.cleaned_data['message']\n return super().form_valid(form)\nget_success_url() is just providing somewhere to redirect to,\nwhich gets used in the default implementation of\nform_valid(). We have to provide our own post() as noted earlier.
It should be obvious that the number of subtle interactions between\nFormMixin and DetailView is\nalready testing our ability to manage things. It’s unlikely you’d want to\nwrite this kind of class yourself.
In this case, it would be fairly easy to just write the post()\nmethod yourself, keeping DetailView as the only generic\nfunctionality, although writing Form handling code\ninvolves a lot of duplication.
Alternatively, it would still be easier than the above approach to\nhave a separate view for processing the form, which could use\nFormView distinct from\nDetailView without concerns.
What we’re really trying to do here is to use two different class\nbased views from the same URL. So why not do just that? We have a very\nclear division here: GET requests should get the\nDetailView (with the Form added to the context\ndata), and POST requests should get the FormView. Let’s\nset up those views first.
The AuthorDisplay view is almost the same as when we\nfirst introduced AuthorDetail; we have to\nwrite our own get_context_data() to make the\nAuthorInterestForm available to the template. We’ll skip the\nget_object() override from before for clarity:
from django import forms\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\nclass AuthorDisplay(DetailView):\n model = Author\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context['form'] = AuthorInterestForm()\n return context\nThen the AuthorInterest is a simple FormView, but we\nhave to bring in SingleObjectMixin so we\ncan find the author we’re talking about, and we have to remember to set\ntemplate_name to ensure that form errors will render the same\ntemplate as AuthorDisplay is using on GET:
from django.http import HttpResponseForbidden\nfrom django.urls import reverse\nfrom django.views.generic import FormView\nfrom django.views.generic.detail import SingleObjectMixin\n\nclass AuthorInterest(SingleObjectMixin, FormView):\n template_name = 'books/author_detail.html'\n form_class = AuthorInterestForm\n model = Author\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n self.object = self.get_object()\n return super().post(request, *args, **kwargs)\n\n def get_success_url(self):\n return reverse('author-detail', kwargs={'pk': self.object.pk})\nFinally we bring this together in a new AuthorDetail view. We\nalready know that calling as_view() on\na class-based view gives us something that behaves exactly like a function\nbased view, so we can do that at the point we choose between the two subviews.
You can of course pass through keyword arguments to\nas_view() in the same way you\nwould in your URLconf, such as if you wanted the AuthorInterest behavior\nto also appear at another URL but using a different template:
from django.views import View\n\nclass AuthorDetail(View):\n\n def get(self, request, *args, **kwargs):\n view = AuthorDisplay.as_view()\n return view(request, *args, **kwargs)\n\n def post(self, request, *args, **kwargs):\n view = AuthorInterest.as_view()\n return view(request, *args, **kwargs)\nThis approach can also be used with any other generic class-based\nviews or your own class-based views inheriting directly from\nView or TemplateView, as it keeps the different\nviews as separate as possible.
Where class-based views shine is when you want to do the same thing many times.\nSuppose you’re writing an API, and every view should return JSON instead of\nrendered HTML.
\nWe can create a mixin class to use in all of our views, handling the\nconversion to JSON once.
\nFor example, a simple JSON mixin might look something like this:
\nfrom django.http import JsonResponse\n\nclass JSONResponseMixin:\n """\n A mixin that can be used to render a JSON response.\n """\n def render_to_json_response(self, context, **response_kwargs):\n """\n Returns a JSON response, transforming 'context' to make the payload.\n """\n return JsonResponse(\n self.get_data(context),\n **response_kwargs\n )\n\n def get_data(self, context):\n """\n Returns an object that will be serialized as JSON by json.dumps().\n """\n # Note: This is *EXTREMELY* naive; in reality, you'll need\n # to do much more complex handling to ensure that arbitrary\n # objects -- such as Django model instances or querysets\n # -- can be serialized as JSON.\n return context\nThis mixin provides a render_to_json_response() method with the same signature\nas render_to_response().\nTo use it, we simply need to mix it into a TemplateView for example,\nand override render_to_response() to call render_to_json_response() instead:
from django.views.generic import TemplateView\n\nclass JSONView(JSONResponseMixin, TemplateView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nEqually we could use our mixin with one of the generic views. We can make our\nown version of DetailView by mixing\nJSONResponseMixin with the\ndjango.views.generic.detail.BaseDetailView – (the\nDetailView before template\nrendering behavior has been mixed in):
from django.views.generic.detail import BaseDetailView\n\nclass JSONDetailView(JSONResponseMixin, BaseDetailView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nThis view can then be deployed in the same way as any other\nDetailView, with exactly the\nsame behavior – except for the format of the response.
If you want to be really adventurous, you could even mix a\nDetailView subclass that is able\nto return both HTML and JSON content, depending on some property of\nthe HTTP request, such as a query argument or a HTTP header. Just mix\nin both the JSONResponseMixin and a\nSingleObjectTemplateResponseMixin,\nand override the implementation of\nrender_to_response()\nto defer to the appropriate rendering method depending on the type of response\nthat the user requested:
from django.views.generic.detail import SingleObjectTemplateResponseMixin\n\nclass HybridDetailView(JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView):\n def render_to_response(self, context):\n # Look for a 'format=json' GET argument\n if self.request.GET.get('format') == 'json':\n return self.render_to_json_response(context)\n else:\n return super().render_to_response(context)\nBecause of the way that Python resolves method overloading, the call to\nsuper().render_to_response(context) ends up calling the\nrender_to_response()\nimplementation of TemplateResponseMixin.