Djangos inbyggda klassbaserade vyer ger en hel del funktionalitet, men en del av den kanske du vill använda separat. Till exempel kanske du vill skriva en vy som renderar en mall för att skapa HTTP-svaret, men du kan inte använda TemplateView; kanske behöver du bara rendera en mall på POST, med GET som gör något helt annat. Även om du kan använda TemplateResponse direkt, kommer detta sannolikt att resultera i duplicerad kod.
Av denna anledning tillhandahåller Django också ett antal mixins som ger mer diskret funktionalitet. Mallrendering, till exempel, är inkapslad i TemplateResponseMixin. Djangos referensdokumentation innehåller full dokumentation av alla mixins.
Två centrala mixins tillhandahålls som hjälper till att tillhandahålla ett konsekvent gränssnitt för att arbeta med mallar i klassbaserade vyer.
\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() själv anropar get_template_names(), som standard kommer att leta upp template_name på den klassbaserade vyn; två andra mixins (SingleObjectTemplateResponseMixin och MultipleObjectTemplateResponseMixin) åsidosätter detta för att ge mer flexibla standardvärden när man hanterar faktiska objekt.
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\nreturns its keyword arguments, but it is common to override this to add\nmore members to the dictionary. You can also use the\nextra_context attribute.
Låt oss titta på hur två av Djangos generiska klassbaserade vyer är uppbyggda av mixins som ger diskret funktionalitet. Vi kommer att överväga DetailView, som renderar en ”detaljerad” vy av ett objekt, och ListView, som kommer att rendera en lista över objekt, vanligtvis från en queryset, och eventuellt paginera dem. Detta kommer att introducera oss till fyra mixins som tillsammans ger användbar funktionalitet när man arbetar med antingen ett enda Django-objekt eller flera objekt.
Det finns också mixins involverade i de generiska redigeringsvyerna (FormView, och de modellspecifika vyerna CreateView, UpdateView och DeleteView), och i de datumbaserade generiska vyerna. Dessa behandlas i mixin referensdokumentation.
DetailView: att arbeta med ett enda Django-objektLink to this heading#För att visa detaljerna i ett objekt måste vi i princip göra två saker: vi måste leta upp objektet och sedan måste vi skapa en TemplateResponse med en lämplig mall och det objektet som kontext.
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, which\nextends TemplateResponseMixin, overriding\nget_template_names() as\ndiscussed 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 views use _form for create and\nupdate views, and _confirm_delete for delete views.)
ListView: arbeta med många Django-objektLink to this heading#Listor med objekt följer ungefär samma mönster: vi behöver en (eventuellt paginerad) lista med objekt, vanligtvis en QuerySet, och sedan måste vi skapa en TemplateResponse med en lämplig mall som använder den listan med objekt.
För att få objekten använder ListView MultipleObjectMixin, som tillhandahåller både get_queryset() och paginate_queryset(). Till skillnad från SingleObjectMixin finns det inget behov av att ange delar av URL:en för att räkna ut vilken queryset som ska användas, så standardvärdet använder attributet queryset eller model på vyklassen. En vanlig anledning att åsidosätta get_queryset() här skulle vara att dynamiskt variera objekten, till exempel beroende på den aktuella användaren eller att utesluta inlägg i framtiden för en blogg.
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.
För att göra en TemplateResponse, använder ListView sedan MultipleObjectTemplateResponseMixin; som med SingleObjectTemplateResponseMixin ovan, åsidosätter detta get_template_names() för att tillhandahålla en rad alternativ, där det vanligaste är <app_label>/<model_name>_list.html, där _list-delen återigen hämtas från attributet template_name_suffix. (De datumbaserade generiska vyerna använder suffix som _archive, _archive_year och så vidare för att använda olika mallar för de olika specialiserade datumbaserade listvyerna)
Nu har vi sett hur Djangos generiska klassbaserade vyer använder de medföljande mixinerna, låt oss titta på andra sätt vi kan kombinera dem. Vi kommer fortfarande att kombinera dem med antingen inbyggda klassbaserade vyer eller andra generiska klassbaserade vyer, men det finns en rad sällsynta problem du kan lösa än vad som tillhandahålls av Django från början.
\n\nSingleObjectMixin med ViewLink to this heading#Om vi vill skriva en klassbaserad vy som bara svarar på POST, subklassar vi View och skriver en post()-metod i subklassen. Men om vi vill att vår bearbetning ska fungera på ett visst objekt, identifierat från URL, vill vi ha den funktionalitet som tillhandahålls av SingleObjectMixin.
We’ll demonstrate this with the Author model we used in the generic\nclass-based views introduction.
Vyer.pyfrom 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\n\nclass RecordInterestView(SingleObjectMixin, View):\n """Records the current user's interest in an author."""\n\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(\n reverse("author-detail", kwargs={"pk": self.object.pk})\n )\nI praktiken skulle du förmodligen vilja registrera intresset i en nyckelvärdesbutik snarare än i en relationsdatabas, så vi har utelämnat den biten. Den enda delen av vyn som behöver oroa sig för att använda SingleObjectMixin är där vi vill leta upp den författare vi är intresserade av, vilket den gör med ett anrop till self.get_object(). Allt annat tas om hand för oss av mixin.
Vi kan enkelt koppla in detta i våra webbadresser:
\nurls.pyfrom django.urls import path\nfrom books.views import RecordInterestView\n\nurlpatterns = [\n # ...\n path(\n "author/<int:pk>/interest/",\n RecordInterestView.as_view(),\n name="author-interest",\n ),\n]\nNotera gruppen med namnet pk, som get_object() använder för att leta upp instansen Author. Du kan också använda en slug, eller någon av de andra funktionerna i SingleObjectMixin.
SingleObjectMixin med ListViewLink to this heading#ListView ger inbyggd paginering, men du kanske vill paginera en lista med objekt som alla är länkade (med en främmande nyckel) till ett annat objekt. I vårt publiceringsexempel kanske du vill paginera genom alla böcker från en viss utgivare.
Ett sätt att göra detta är att kombinera ListView med SingleObjectMixin, så att queryset för den paginerade listan med böcker kan hänga på förlaget som hittas som ett enda objekt. För att kunna göra detta måste vi ha två olika querysets:
Book queryset för användning av ListViewEftersom vi har tillgång till det förlag vars böcker vi vill lista, åsidosätter vi get_queryset() och använder förlagets reverse foreign key manager.
Publisher queryset for use in get_object()Vi kommer att förlita oss på standardimplementeringen av get_object() för att hämta rätt Publisher-objekt. Vi måste dock uttryckligen skicka ett queryset-argument eftersom standardimplementeringen av get_object() annars skulle anropa get_queryset() som vi har åsidosatt för att returnera Book-objekt istället för Publisher-objekt.
Nu kan vi skriva en ny PublisherDetailView:
from django.views.generic import ListView\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Publisher\n\n\nclass PublisherDetailView(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()\nLägg märke till hur vi anger self.object inom get() så att vi kan använda det igen senare i get_context_data() och get_queryset(). Om du inte anger template_name, kommer mallen som standard att välja det normala ListView-valet, som i det här fallet skulle vara "books/book_list.html" eftersom det är en lista över böcker; ListView vet ingenting om SingleObjectMixin`, så den har ingen aning om att den här vyn har något att göra med en Publisher.
paginate_by är avsiktligt liten i exemplet så att du inte behöver skapa massor av böcker för att se att pagineringen fungerar! Här är den mall du vill använda:
{% 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 %}\nGenerellt kan du använda TemplateResponseMixin och SingleObjectMixin när du behöver deras funktionalitet. Som visas ovan kan du med lite försiktighet till och med kombinera SingleObjectMixin med ListView. Saker och ting blir dock alltmer komplexa när du försöker göra det, och en bra tumregel är:
För att visa vad som händer när man försöker bli mer sofistikerad, visar vi ett exempel som offrar läsbarhet och underhåll när det finns en enklare lösning. Låt oss först titta på ett naivt försök att kombinera DetailView med FormMixin för att göra det möjligt för oss att POST en Django Form till samma URL som vi visar ett objekt med DetailView.
FormMixin med DetailViewLink to this heading#Tänk tillbaka på vårt tidigare exempel där vi använde View och SingleObjectMixin tillsammans. Vi registrerade en användares intresse för en viss författare; säg nu att vi vill låta dem lämna ett meddelande där de säger varför de gillar dem. Återigen, låt oss anta att vi inte kommer att lagra detta i en relationsdatabas utan istället i något mer esoteriskt som vi inte kommer att oroa oss för här.
Vid denna tidpunkt är det naturligt att nå en Form för att kapsla in den information som skickas från användarens webbläsare till Django. Säg också att vi är starkt investerade i REST, så vi vill använda samma URL för att visa författaren som för att fånga meddelandet från användaren. Låt oss skriva om vår AuthorDetailView för att göra det.
Vi behåller GET-hanteringen från DetailView, även om vi måste lägga till en Form i kontextdata så att vi kan rendera den i mallen. Vi kommer också att vilja dra in formulärbehandling från FormMixin, och skriva lite kod så att formuläret på POST anropas på lämpligt sätt.
Vår nya AuthorDetailView ser ut så här:
# 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\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\n\nclass AuthorDetailView(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() ger någonstans att omdirigera till, som används i standardimplementeringen av form_valid(). Vi måste tillhandahålla vår egen post() som tidigare nämnts.
Antalet subtila interaktioner mellan FormMixin och DetailView testar redan vår förmåga att hantera saker. Det är osannolikt att du skulle vilja skriva den här typen av klass själv.
I det här fallet kan du skriva post()-metoden själv och behålla DetailView som den enda generiska funktionaliteten, även om det innebär mycket dubbelarbete att skriva Form-hanteringskod.
Alternativt skulle det fortfarande vara mindre arbete än ovanstående tillvägagångssätt att ha en separat vy för bearbetning av formuläret, som kan använda FormView skilt från DetailView utan problem.
Vad vi egentligen försöker göra här är att använda två olika klassbaserade vyer från samma URL. Så varför inte göra just det? Vi har en mycket tydlig uppdelning här: GET förfrågningar bör få DetailView (med Form läggs till i kontextdata), och POST förfrågningar bör få FormView. Låt oss ställa in dessa vyer först.
Vyn AuthorDetailView är nästan densamma som när vi först introducerade AuthorDetailView; vi måste skriva vår egen get_context_data() för att göra AuthorInterestForm tillgänglig för mallen. Vi hoppar över get_object() överskrivningen från tidigare för tydlighetens skull:
from django import forms\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\n\nclass AuthorDetailView(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\nDå är AuthorInterestFormView en FormView, men vi måste ta in SingleObjectMixin så att vi kan hitta den författare vi pratar om, och vi måste komma ihåg att ställa in template_name för att säkerställa att formulärfel kommer att göra samma mall som AuthorDetailView använder på 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\n\nclass AuthorInterestFormView(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 AuthorView 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 pass through keyword arguments to\nas_view() in the same way you\nwould in your URLconf, such as if you wanted the AuthorInterestFormView\nbehavior to also appear at another URL but using a different template:
from django.views import View\n\n\nclass AuthorView(View):\n def get(self, request, *args, **kwargs):\n view = AuthorDetailView.as_view()\n return view(request, *args, **kwargs)\n\n def post(self, request, *args, **kwargs):\n view = AuthorInterestFormView.as_view()\n return view(request, *args, **kwargs)\nDetta tillvägagångssätt kan också användas med alla andra generiska klassbaserade vyer eller dina egna klassbaserade vyer som ärver direkt från View eller TemplateView, eftersom det håller de olika vyerna så separata som möjligt.
Klassbaserade vyer är perfekta när du vill göra samma sak många gånger. Anta att du skriver ett API och att varje vy ska returnera JSON istället för renderad HTML.
\nVi kan skapa en mixin-klass som kan användas i alla våra vyer och hantera konverteringen till JSON en gång.
\nTill exempel kan en JSON-mixin se ut ungefär så här:
\nfrom django.http import JsonResponse\n\n\nclass JSONResponseMixin:\n """\n A mixin that can be used to render a JSON response.\n """\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(self.get_data(context), **response_kwargs)\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\nsignature as\nrender_to_response().\nTo use it, we need to mix it into a TemplateView for example, and override\nrender_to_response() to call render_to_json_response() instead:
from django.views.generic import TemplateView\n\n\nclass JSONView(JSONResponseMixin, TemplateView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nPå samma sätt kan vi använda vår mixin med en av de generiska vyerna. Vi kan göra vår egen version av DetailView genom att blanda JSONResponseMixin med BaseDetailView – (DetailView innan mallrenderingsbeteendet har blandats in):
from django.views.generic.detail import BaseDetailView\n\n\nclass JSONDetailView(JSONResponseMixin, BaseDetailView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nDenna vy kan sedan distribueras på samma sätt som alla andra DetailView, med exakt samma beteende - förutom svarets format.
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 an HTTP header. Mix in both the\nJSONResponseMixin 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\n\nclass HybridDetailView(\n JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView\n):\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.