Klassbaserade vyer är ett alternativt sätt att implementera vyer som Python-objekt i stället för funktioner. De ersätter inte funktionsbaserade vyer, men har vissa skillnader och fördelar jämfört med funktionsbaserade vyer:
\nOrganisering av kod relaterad till specifika HTTP-metoder (GET, POST, etc.) kan hanteras med separata metoder istället för villkorlig förgrening.
Objektorienterade tekniker som mixins (multiple inheritance) kan användas för att dela upp koden i återanvändbara komponenter.
I början fanns det bara view-funktionskontraktet, Django skickade din funktion en HttpRequest och förväntade sig tillbaka en HttpResponse. Detta var omfattningen av vad Django tillhandahöll.
Redan tidigt insåg man att det fanns vanliga idiom och mönster i utvecklingen av vyer. Funktionsbaserade generiska vyer introducerades för att abstrahera dessa mönster och underlätta utvecklingen av vyer för de vanligaste fallen.
\nProblemet med funktionsbaserade generiska vyer är att de visserligen täcker de enkla fallen väl, men att det inte finns något sätt att utöka eller anpassa dem utöver vissa konfigurationsalternativ, vilket begränsar deras användbarhet i många verkliga tillämpningar.
\nKlassbaserade generiska vyer skapades med samma mål som funktionsbaserade generiska vyer, att göra det enklare att utveckla vyer. Det sätt på vilket lösningen implementeras, genom användning av mixins, ger dock en verktygslåda som resulterar i att klassbaserade generiska vyer är mer utbyggbara och flexibla än sina funktionsbaserade motsvarigheter.
\nOm du tidigare har provat funktionsbaserade generiska vyer och funnit dem otillräckliga, bör du inte se klassbaserade generiska vyer som en klassbaserad motsvarighet, utan snarare som ett nytt sätt att lösa de ursprungliga problem som generiska vyer var avsedda att lösa.
\nVerktygslådan med basklasser och mixins som Django använder för att bygga klassbaserade generiska vyer är byggd för maximal flexibilitet och har därför många hooks i form av standardmetoderealiseringar och attribut som du troligen inte kommer att bry dig om i de enklaste användningsfallen. I stället för att begränsa dig till ett klassbaserat attribut för form_class använder implementeringen till exempel en get_form-metod, som anropar en get_form_class-metod, som i sin standardimplementering returnerar klassens form_class-attribut. Detta ger dig flera alternativ för att ange vilket formulär som ska användas, från ett attribut till en helt dynamisk, anropsbar hook. Dessa alternativ verkar lägga till ihålig komplexitet för enkla situationer, men utan dem skulle mer avancerade mönster vara begränsade.
I grunden innebär en klassbaserad vy att du kan svara på olika HTTP-begärandemetoder med olika klassinstansmetoder, istället för med villkorligt förgrenad kod i en enda vyfunktion.
\nSå där koden för att hantera HTTP GET i en vyfunktion skulle se ut ungefär som:
from django.http import HttpResponse\n\n\ndef my_view(request):\n if request.method == "GET":\n # <view logic>\n return HttpResponse("result")\nI en klassbaserad vy skulle detta bli:
\nfrom django.http import HttpResponse\nfrom django.views import View\n\n\nclass MyView(View):\n def get(self, request):\n # <view logic>\n return HttpResponse("result")\nEftersom Djangos URL-resolver förväntar sig att skicka begäran och tillhörande argument till en anropbar funktion, inte en klass, har klassbaserade vyer en klassmetod as_view() som returnerar en funktion som kan anropas när en begäran kommer för en URL som matchar det associerade mönstret. Funktionen skapar en instans av klassen, anropar setup() för att initialisera dess attribut och anropar sedan dess dispatch()-metod. dispatch tittar på begäran för att avgöra om det är en GET, POST, etc, och vidarebefordrar begäran till en matchande metod om en sådan är definierad, eller ger upphov till HttpResponseNotAllowed om inte:
# urls.py\nfrom django.urls import path\nfrom myapp.views import MyView\n\nurlpatterns = [\n path("about/", MyView.as_view()),\n]\nDet är värt att notera att det som din metod returnerar är identiskt med det som du returnerar från en funktionsbaserad vy, nämligen någon form av HttpResponse. Detta innebär att http shortcuts eller TemplateResponse-objekt är giltiga att använda i en klassbaserad vy.
Även om en minimal klassbaserad vy inte kräver några klassattribut för att utföra sitt jobb, är klassattribut användbara i många klassbaserade designer, och det finns två sätt att konfigurera eller ange klassattribut.
\nDen första är det vanliga Python-sättet att subklassa och åsidosätta attribut och metoder i subklassen. Så om din överordnade klass hade ett attribut greeting så här:
from django.http import HttpResponse\nfrom django.views import View\n\n\nclass GreetingView(View):\n greeting = "Good Day"\n\n def get(self, request):\n return HttpResponse(self.greeting)\nDu kan åsidosätta det i en subklass:
\nclass MorningGreetingView(GreetingView):\n greeting = "Morning to ya"\nEtt annat alternativ är att konfigurera klassattribut som nyckelordsargument till as_view()-anropet i URLconf:
urlpatterns = [\n path("about/", GreetingView.as_view(greeting="G'day")),\n]\nMixins är en form av multipel nedärvning där beteenden och attribut från flera överordnade klasser kan kombineras.
\nTill exempel finns det i de generiska klassbaserade vyerna en mixin som heter TemplateResponseMixin vars primära syfte är att definiera metoden render_to_response(). I kombination med beteendet i basklassen View blir resultatet en klass av typen TemplateView som skickar förfrågningar till lämpliga matchningsmetoder (ett beteende som definieras i basklassen View) och som har en render_to_response()-metoden som använder ett template_name-attribut för att returnera ett TemplateResponse-objekt (ett beteende som definieras i TemplateResponseMixin).
Mixins är ett utmärkt sätt att återanvända kod i flera klasser, men de har ett visst pris. Ju mer din kod är utspridd bland mixins, desto svårare blir det att läsa en underordnad klass och veta exakt vad den gör, och desto svårare blir det att veta vilka metoder från vilka mixins som ska åsidosättas om du subklassar något som har ett djupt arvsträd.
\nObservera också att du bara kan ärva från en generisk vy - det vill säga, bara en föräldraklass kan ärva från View och resten (om någon) bör vara mixins. Att försöka ärva från mer än en klass som ärver från View - till exempel att försöka använda ett formulär högst upp i en lista och kombinera ProcessFormView och ListView - kommer inte att fungera som förväntat.
En grundläggande funktionsbaserad vy som hanterar formulär kan se ut ungefär så här:
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import MyForm\n\n\ndef myview(request):\n if request.method == "POST":\n form = MyForm(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect("/success/")\n else:\n form = MyForm(initial={"key": "value"})\n\n return render(request, "form_template.html", {"form": form})\nEn liknande klassbaserad vy kan se ut på följande sätt:
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\nfrom django.views import View\n\nfrom .forms import MyForm\n\n\nclass MyFormView(View):\n form_class = MyForm\n initial = {"key": "value"}\n template_name = "form_template.html"\n\n def get(self, request, *args, **kwargs):\n form = self.form_class(initial=self.initial)\n return render(request, self.template_name, {"form": form})\n\n def post(self, request, *args, **kwargs):\n form = self.form_class(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect("/success/")\n\n return render(request, self.template_name, {"form": form})\nDetta är ett minimifall, men du kan se att du då skulle ha möjlighet att anpassa den här vyn genom att åsidosätta något av klassattributen, t.ex. form_class, via URLconf-konfiguration, eller subklassa och åsidosätta en eller flera av metoderna (eller båda!).
Utökningen av klassbaserade vyer är inte begränsad till att använda mixins. Du kan också använda dekoratorer. Eftersom klassbaserade vyer inte är funktioner fungerar dekorering av dem olika beroende på om du använder as_view() eller skapar en subklass.
Du kan justera klassbaserade vyer genom att dekorera resultatet av as_view()-metoden. Det enklaste stället att göra detta är i URLconf där du distribuerar din vy:
from django.contrib.auth.decorators import login_required, permission_required\nfrom django.views.generic import TemplateView\n\nfrom .views import VoteView\n\nurlpatterns = [\n path("about/", login_required(TemplateView.as_view(template_name="secret.html"))),\n path("vote/", permission_required("polls.can_vote")(VoteView.as_view())),\n]\nDenna metod tillämpar dekoratorn per instans. Om du vill att varje instans av en vy ska dekoreras måste du använda ett annat tillvägagångssätt.
\nFör att dekorera varje instans av en klassbaserad vy måste du dekorera själva klassdefinitionen. För att göra detta tillämpar du dekoratorn på klassens dispatch()-metod.
En metod i en klass är inte riktigt samma sak som en fristående funktion, så du kan inte bara använda en funktionsdekorator på metoden - du måste först omvandla den till en metoddekorator. Dekoratorn method_decorator omvandlar en funktionsdekorator till en metoddekorator så att den kan användas på en instansmetod. Till exempel:
from django.contrib.auth.decorators import login_required\nfrom django.utils.decorators import method_decorator\nfrom django.views.generic import TemplateView\n\n\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n\n @method_decorator(login_required)\n def dispatch(self, *args, **kwargs):\n return super().dispatch(*args, **kwargs)\nEller, mer kortfattat, du kan dekorera klassen istället och skicka namnet på den metod som ska dekoreras som nyckelordsargumentet name:
@method_decorator(login_required, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\nOm du har en uppsättning vanliga dekoratorer som används på flera ställen kan du definiera en lista eller tupel av dekoratorer och använda detta istället för att anropa method_decorator() flera gånger. Dessa två klasser är likvärdiga:
decorators = [never_cache, login_required]\n\n\n@method_decorator(decorators, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\n\n\n@method_decorator(never_cache, name="dispatch")\n@method_decorator(login_required, name="dispatch")\nclass ProtectedView(TemplateView):\n template_name = "secret.html"\nDekoratörerna behandlar en begäran i den ordning som de skickas till dekoratören. I exemplet kommer never_cache() att bearbeta begäran före login_required().
I det här exemplet kommer varje instans av ProtectedView att ha inloggningsskydd. Dessa exempel använder login_required, men samma beteende kan erhållas genom att använda LoginRequiredMixin.