Using mixins with class-based views

This is an advanced topic. A working knowledge of Django'sclass-based views is advised before exploring thesetechniques.

Django's built-in class-based views provide a lot of functionality,but some of it you may want to use separately. For instance, you maywant to write a view that renders a template to make the HTTPresponse, but you can't use; perhaps you need torender a template only on POST, with GET doing something elseentirely. While you could useTemplateResponse directly, thiswill likely result in duplicate code.

For this reason, Django also provides a number of mixins that providemore discrete functionality. Template rendering, for instance, isencapsulated in the. The Djangoreference documentation contains full documentation of all themixins.

Two central mixins are provided that help in providing a consistentinterface to working with templates in class-based views.

• Every built in view which returns aTemplateResponse will call themethod that TemplateResponseMixin provides. Most of the time thiswill be called for you (for instance, it is called by the get() methodimplemented by both TemplateView and); similarly, it's unlikelythat you'll need to override it, although if you want your response toreturn something not rendered via a Django template then you'll want to doit. For an example of this, see the JSONResponseMixin example.

render_to_response() itself calls,which by default will just look uptemplate_name onthe class-based view; two other mixins(andMultipleObjectTemplateResponseMixin)override this to provide more flexible defaults when dealing with actualobjects.

• Every built in view which needs context data, such as for rendering atemplate (including TemplateResponseMixin above), should callget_context_data() passingany data they want to ensure is in there as keyword arguments.get_context_data() returns a dictionary; in ContextMixin itsimply returns its keyword arguments, but it is common to override this toadd more members to the dictionary. You can also use the attribute.

Let's look at how two of Django's generic class-based views are builtout of mixins providing discrete functionality. We'll considerDetailView, which renders a"detail" view of an object, and, which will render a listof objects, typically from a queryset, and optionally paginatethem. This will introduce us to four mixins which between them provideuseful functionality when working with either a single Django object,or multiple objects.

There are also mixins involved in the generic edit views(FormView, and the model-specificviews ,UpdateView and), and in thedate-based generic views. These arecovered in the mixin referencedocumentation.

To show the detail of an object, we basically need to do two things:we need to look up the object and then we need to make a with a suitable template,and that object as context.

To get the object, DetailViewrelies on ,which provides aget_object()method that figures out the object based on the URL of the request (itlooks for pk and slug keyword arguments as declared in theURLConf, and looks the object up either from the attributeon the view, or thequerysetattribute if that's provided). SingleObjectMixin also overrides,which is used across all Django's built in class-based views to supplycontext data for template renders.

To then make a TemplateResponse, usesSingleObjectTemplateResponseMixin,which extends ,overridingget_template_names()as discussed above. It actually provides a fairly sophisticated set of options,but the main one that most people are going to use is<app_label>/<model_name>_detail.html. The _detail part can be changedby settingon a subclass to something else. (For instance, the generic editviews use _form for create and update views, and_confirm_delete for delete views.)

ListView: working with many Django objects

Lists of objects follow roughly the same pattern: we need a (possiblypaginated) list of objects, typically aQuerySet, and then we need to make a with a suitable templateusing that list of objects.

To get the objects, ListView uses, whichprovides bothget_queryset()and. Unlikewith SingleObjectMixin, there's no needto key off parts of the URL to figure out the queryset to work with, so thedefault just uses the ormodel attributeon the view class. A common reason to overridehere would be to dynamically vary the objects, such as depending onthe current user or to exclude posts in the future for a blog.

MultipleObjectMixin also overrides toinclude appropriate context variables for pagination (providingdummies if pagination is disabled). It relies on object_list beingpassed in as a keyword argument, which ListView arranges forit.

To make a ,ListView then uses;as with SingleObjectTemplateResponseMixinabove, this overrides get_template_names() to provide ,with the most commonly-used being<app_label>/<model_name>_list.html, with the _list part againbeing taken from thetemplate_name_suffixattribute. (The date based generic views use suffixes such as _archive,_archive_year and so on to use different templates for the variousspecialized date-based list views.)

Now we've seen how Django's generic class-based views use the providedmixins, let's look at other ways we can combine them. Of course we'restill going to be combining them with either built-in class-basedviews, or other generic class-based views, but there are a range ofrarer problems you can solve than are provided for by Django out ofthe box.

警告

Not all mixins can be used together, and not all generic classbased views can be used with all other mixins. Here we present afew examples that do work; if you want to bring together otherfunctionality then you'll have to consider interactions betweenattributes and methods that overlap between the different classesyou're using, and how will affect whichversions of the methods will be called in what order.

The reference documentation for Django's class-basedviews and will help you inunderstanding which attributes and methods are likely to causeconflict between different classes and mixins.

If in doubt, it's often better to back off and base your work onView or , perhaps withSingleObjectMixin and. Although youwill probably end up writing more code, it is more likely to be clearlyunderstandable to someone else coming to it later, and with fewerinteractions to worry about you will save yourself some thinking. (Ofcourse, you can always dip into Django's implementation of the genericclass-based views for inspiration on how to tackle problems.)

If we want to write a simple class-based view that responds only toPOST, we'll subclass View andwrite a post() method in the subclass. However if we want ourprocessing to work on a particular object, identified from the URL,we'll want the functionality provided by.

views.py

In practice you'd probably want to record the interest in a key-valuestore rather than in a relational database, so we've left that bitout. The only bit of the view that needs to worry about using is where we want tolook up the author we're interested in, which it just does with a simple callto self.get_object(). Everything else is taken care of for us by themixin.

We can hook this into our URLs easily enough:

urls.py

from django.urls import path
from books.views import RecordInterest
 
urlpatterns = [
    #...
    path('author/<int:pk>/interest/', RecordInterest.as_view(), name='author-interest'),
]

Note the pk named group, which usesto look up the Author instance. You could also use a slug, orany of the other features ofSingleObjectMixin.

Using SingleObjectMixin with ListView

ListView provides built-inpagination, but you might want to paginate a list of objects that areall linked (by a foreign key) to another object. In our publishingexample, you might want to paginate through all the books by aparticular publisher.

One way to do this is to combine withSingleObjectMixin, so that the querysetfor the paginated list of books can hang off the publisher found as the singleobject. In order to do this, we need to have two different querysets:

• Book queryset for use by
• Since we have access to the Publisher whose books we want to list, wesimply override get_queryset() and use the Publisher’sreverse foreign key manager.
• Publisher queryset for use in
• We'll rely on the default implementation of get_object() to fetch thecorrect Publisher object.However, we need to explicitly pass a queryset argument becauseotherwise the default implementation of get_object() would callget_queryset() which we have overridden to return Book objectsinstead of Publisher ones.

注解

We have to think carefully about get_context_data().Since both SingleObjectMixin and willput things in the context data under the value ofcontext_object_name if it's set, we'll instead explicitlyensure the Publisher is in the context data. ListViewwill add in the suitable page_obj and paginator for usproviding we remember to call super().

Now we can write a new PublisherDetail:

from django.views.generic import ListView
from django.views.generic.detail import SingleObjectMixin
from books.models import Publisher
 
class PublisherDetail(SingleObjectMixin, ListView):
    paginate_by = 2
    template_name = "books/publisher_detail.html"
 
    def get(self, request, *args, **kwargs):
        self.object = self.get_object(queryset=Publisher.objects.all())
        return super().get(request, *args, **kwargs)
 
    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context['publisher'] = self.object
        return context
 
        return self.object.book_set.all()

Notice how we set self.object within get() so wecan use it again later in get_context_data() and get_queryset().If you don't set template_name, the template will default to the normal choice, which in this case would be"books/book_list.html" because it's a list of books;ListView knows nothing about, so it doesn't haveany clue this view is anything to do with a Publisher.

The paginate_by is deliberately small in the example so you don'thave to create lots of books to see the pagination working! Here's thetemplate you'd want to use:

{% extends "base.html" %}
 
{% block content %}
    <h2>Publisher {{ publisher.name }}</h2>
 
    <ol>
      {% for book in page_obj %}
        <li>{{ book.title }}</li>
      {% endfor %}
    </ol>
 
    <div class="pagination">
        <span class="step-links">
            {% if page_obj.has_previous %}
                <a href="?page={{ page_obj.previous_page_number }}">previous</a>
            {% endif %}
 
            <span class="current">
                Page {{ page_obj.number }} of {{ paginator.num_pages }}.
            </span>
 
            {% if page_obj.has_next %}
                <a href="?page={{ page_obj.next_page_number }}">next</a>
            {% endif %}
        </span>
    </div>
{% endblock %}

Generally you can useTemplateResponseMixin and when you needtheir functionality. As shown above, with a bit of care you can evencombine SingleObjectMixin withListView. However things getincreasingly complex as you try to do so, and a good rule of thumb is:

提示

Each of your views should use only mixins or views from one of thegroups of generic class-based views: , editing anddate. For example it's fine to combine (built in view) withMultipleObjectMixin (generic list), butyou're likely to have problems combining SingleObjectMixin (genericdetail) with MultipleObjectMixin (generic list).

To show what happens when you try to get more sophisticated, we showan example that sacrifices readability and maintainability when thereis a simpler solution. First, let's look at a naive attempt to combine with to enable us toPOST a Django to the same URL as we'redisplaying an object using DetailView.

Think back to our earlier example of using andSingleObjectMixin together. We wererecording a user's interest in a particular author; say now that we want tolet them leave a message saying why they like them. Again, let's assume we'renot going to store this in a relational database but instead insomething more esoteric that we won't worry about here.

At this point it's natural to reach for a toencapsulate the information sent from the user's browser to Django. Say alsothat we're heavily invested in REST, so we want to use the same URL fordisplaying the author as for capturing the message from theuser. Let's rewrite our AuthorDetailView to do that.

We'll keep the GET handling from , althoughwe'll have to add a Form into the context data so we canrender it in the template. We'll also want to pull in form processingfrom , and write a bit ofcode so that on POST the form gets called appropriately.

注解

Our new AuthorDetail looks like this:

get_success_url() is just providing somewhere to redirect to,which gets used in the default implementation ofform_valid(). We have to provide our own post() asnoted earlier, and override get_context_data() to make theForm available in the context data.

A better solution

It should be obvious that the number of subtle interactions betweenFormMixin and isalready testing our ability to manage things. It's unlikely you'd want towrite this kind of class yourself.

In this case, it would be fairly easy to just write the post()method yourself, keeping DetailView as the only genericfunctionality, although writing handling codeinvolves a lot of duplication.

Alternatively, it would still be easier than the above approach tohave a separate view for processing the form, which could useFormView distinct from without concerns.

What we're really trying to do here is to use two different classbased views from the same URL. So why not do just that? We have a veryclear division here: GET requests should get theDetailView (with the added to the contextdata), and POST requests should get the FormView. Let'sset up those views first.

The AuthorDisplay view is almost the same as ; we have towrite our own get_context_data() to make theAuthorInterestForm available to the template. We'll skip theget_object() override from before for clarity:

from django import forms
from django.views.generic import DetailView
from books.models import Author
 
class AuthorInterestForm(forms.Form):
    message = forms.CharField()
 
class AuthorDisplay(DetailView):
    model = Author
 
    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context['form'] = AuthorInterestForm()
        return context

Then the AuthorInterest is a simple FormView, but wehave to bring in so wecan find the author we're talking about, and we have to remember to settemplate_name to ensure that form errors will render the sametemplate as AuthorDisplay is using on GET:

from django.http import HttpResponseForbidden
from django.urls import reverse
from django.views.generic.detail import SingleObjectMixin
 
class AuthorInterest(SingleObjectMixin, FormView):
    template_name = 'books/author_detail.html'
    form_class = AuthorInterestForm
    model = Author
 
    def post(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return HttpResponseForbidden()
        self.object = self.get_object()
        return super().post(request, *args, **kwargs)
 
    def get_success_url(self):
        return reverse('author-detail', kwargs={'pk': self.object.pk})

Finally we bring this together in a new AuthorDetail view. Wealready know that calling as_view() ona class-based view gives us something that behaves exactly like a functionbased view, so we can do that at the point we choose between the two subviews.

You can of course pass through keyword arguments to in the same way youwould in your URLconf, such as if you wanted the AuthorInterest behaviorto also appear at another URL but using a different template:

from django.views import View
 
class AuthorDetail(View):
 
    def get(self, request, *args, **kwargs):
        view = AuthorDisplay.as_view()
        return view(request, *args, **kwargs)
 
    def post(self, request, *args, **kwargs):
        view = AuthorInterest.as_view()
        return view(request, *args, **kwargs)

This approach can also be used with any other generic class-basedviews or your own class-based views inheriting directly fromView or , as it keeps the differentviews as separate as possible.

Where class-based views shine is when you want to do the same thing many times.Suppose you're writing an API, and every view should return JSON instead ofrendered HTML.

We can create a mixin class to use in all of our views, handling theconversion to JSON once.

For example, a simple JSON mixin might look something like this:

注解

Check out the Serializing Django objects documentation for moreinformation on how to correctly transform Django models and querysets intoJSON.

This mixin provides a render_to_json_response() method with the same signatureas .To use it, we simply need to mix it into a TemplateView for example,and override render_to_response() to call render_to_json_response() instead:

from django.views.generic import TemplateView
 
class JSONView(JSONResponseMixin, TemplateView):
    def render_to_response(self, context, **response_kwargs):
        return self.render_to_json_response(context, **response_kwargs)

Equally we could use our mixin with one of the generic views. We can make ourown version of DetailView by mixingJSONResponseMixin with thedjango.views.generic.detail.BaseDetailView — (the before templaterendering behavior has been mixed in):

from django.views.generic.detail import BaseDetailView
 
class JSONDetailView(JSONResponseMixin, BaseDetailView):
    def render_to_response(self, context, **response_kwargs):
        return self.render_to_json_response(context, **response_kwargs)

This view can then be deployed in the same way as any otherDetailView, with exactly thesame behavior — except for the format of the response.

If you want to be really adventurous, you could even mix a subclass that is ableto return both HTML and JSON content, depending on some property ofthe HTTP request, such as a query argument or a HTTP header. Just mixin both the JSONResponseMixin and aSingleObjectTemplateResponseMixin,and override the implementation ofto defer to the appropriate rendering method depending on the type of responsethat the user requested:

from django.views.generic.detail import SingleObjectTemplateResponseMixin
 
class HybridDetailView(JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView):
    def render_to_response(self, context):
        # Look for a 'format=json' GET argument
        if self.request.GET.get('format') == 'json':
            return self.render_to_json_response(context)
        else: