Använda mixins med klassbaserade vyerLink to this heading#

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.

För att hämta objektet förlitar sig DetailView på SingleObjectMixin, som tillhandahåller en get_object()-metod som räknar ut objektet baserat på webbadressen för begäran (den letar efter pk och slug nyckelordsargument som deklareras i URLConf, och letar upp objektet antingen från attributet model på vyn, eller attributet queryset om det tillhandahålls). SingleObjectMixin åsidosätter också get_context_data(), som används i alla Djangos inbyggda klassbaserade vyer för att tillhandahålla kontextdata för mallåtergivning.

För att sedan skapa en TemplateResponse, använder DetailView SingleObjectTemplateResponseMixin, som utökar TemplateResponseMixin, och åsidosätter get_template_names() som diskuterats ovan. Det ger faktiskt en ganska sofistikerad uppsättning alternativ, men det viktigaste som de flesta kommer att använda är <app_label>/<model_name>_detail.html. Delen _detail kan ändras genom att ställa in template_name_suffix på en underklass till något annat. (Till exempel använder generic edit views _form för att skapa och uppdatera vyer, och _confirm_delete för att ta bort vyer)

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 åsidosätter också get_context_data() för att inkludera lämpliga kontextvariabler för paginering (tillhandahåller dummies om paginering är inaktiverad). Den förlitar sig på att object_list skickas in som ett nyckelordsargument, vilket ListView ordnar för den.

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)

Använda SingleObjectMixin 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.

Vi ska demonstrera detta med modellen Author som vi använde i generic class-based views introduction.

from django.http import HttpResponseForbidden, HttpResponseRedirect
from django.urls import reverse
from django.views import View
from django.views.generic.detail import SingleObjectMixin
from books.models import Author


class RecordInterestView(SingleObjectMixin, View):
    """Records the current user's interest in an author."""

    model = Author

    def post(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return HttpResponseForbidden()

        # Look up the author we're interested in.
        self.object = self.get_object()
        # Actually record interest somehow here!

        return HttpResponseRedirect(
            reverse("author-detail", kwargs={"pk": self.object.pk})
        )

I 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:

from django.urls import path
from books.views import RecordInterestView

urlpatterns = [
    # ...
    path(
        "author/<int:pk>/interest/",
        RecordInterestView.as_view(),
        name="author-interest",
    ),
]

Notera 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.

Använda 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 ListView

Eftersom 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 för användning i 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
from django.views.generic.detail import SingleObjectMixin
from books.models import Publisher


class PublisherDetailView(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

    def get_queryset(self):
        return self.object.book_set.all()

Lä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" %}

{% 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 %}

Använda 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.
# It is provided as part of a discussion of problems you can
# run into when combining different generic class-based view
# functionality that is not designed to be used together.

from django import forms
from django.http import HttpResponseForbidden
from django.urls import reverse
from django.views.generic import DetailView
from django.views.generic.edit import FormMixin
from books.models import Author


class AuthorInterestForm(forms.Form):
    message = forms.CharField()


class AuthorDetailView(FormMixin, DetailView):
    model = Author
    form_class = AuthorInterestForm

    def get_success_url(self):
        return reverse("author-detail", kwargs={"pk": self.object.pk})

    def post(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return HttpResponseForbidden()
        self.object = self.get_object()
        form = self.get_form()
        if form.is_valid():
            return self.form_valid(form)
        else:
            return self.form_invalid(form)

    def form_valid(self, form):
        # Here, we would record the user's interest using the message
        # passed in form.cleaned_data['message']
        return super().form_valid(form)

get_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.

En bättre lösningLink to this heading#

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.

En alternativ bättre lösningLink to this heading#

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
from django.views.generic import DetailView
from books.models import Author


class AuthorInterestForm(forms.Form):
    message = forms.CharField()


class AuthorDetailView(DetailView):
    model = Author

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["form"] = AuthorInterestForm()
        return context

Då ä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
from django.urls import reverse
from django.views.generic import FormView
from django.views.generic.detail import SingleObjectMixin


class AuthorInterestFormView(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})

Slutligen sammanför vi detta i en ny vy AuthorView. Vi vet redan att anrop av as_view() på en klassbaserad vy ger oss något som beter sig exakt som en funktionsbaserad vy, så vi kan göra det vid den punkt där vi väljer mellan de två undervyerna.

Du kan skicka nyckelordsargument till as_view() på samma sätt som du skulle göra i din URLconf, till exempel om du vill att beteendet AuthorInterestFormView också ska visas på en annan URL men med en annan mall:

from django.views import View


class AuthorView(View):
    def get(self, request, *args, **kwargs):
        view = AuthorDetailView.as_view()
        return view(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        view = AuthorInterestFormView.as_view()
        return view(request, *args, **kwargs)

Detta 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.