Följande tre klasser tillhandahåller mycket av den funktionalitet som behövs för att skapa Django-vyer. Du kan tänka på dem som föräldrar vyer, som kan användas av sig själva eller ärvas från. De kanske inte tillhandahåller alla funktioner som krävs för projekt, i vilket fall det finns Mixins och generiska klassbaserade vyer.
\nMånga av Djangos inbyggda klassbaserade vyer ärver från andra klassbaserade vyer eller olika mixins. Eftersom denna arvskedja är mycket viktig dokumenteras förfädersklasserna under avsnittets titel Förfäder (MRO). MRO är en akronym för Method Resolution Order.
\nViewLink to this heading#Basklassen för vyn. Alla andra klassbaserade vyer ärver från denna basklass. Det är inte strikt en generisk vy och kan därför också importeras från django.views.
Flödesschema för metod
\n\nExempel på views.py:
\nfrom django.http import HttpResponse\nfrom django.views import View\n\n\nclass MyView(View):\n def get(self, request, *args, **kwargs):\n return HttpResponse("Hello, World!")\nExempel urls.py:
\nfrom django.urls import path\n\nfrom myapp.views import MyView\n\nurlpatterns = [\n path("mine/", MyView.as_view(), name="my-view"),\n]\nAttribut
\nListan över HTTP-metodnamn som den här vyn accepterar.
\nStandard:
\n["get", "post", "put", "patch", "delete", "head", "options", "trace"]\nMetoder
\nReturnerar en anropsbar vy som tar emot en begäran och returnerar ett svar:
\nresponse = MyView.as_view()(request)\nDen returnerade vyn har attributen view_class och view_initkwargs.
När vyn anropas under request/response-cykeln, tilldelar metoden setup() HttpRequest till vyns attribut request, och alla positionella och/eller nyckelordsargument fångade från URL-mönstret till attributen args respektive kwargs. Sedan anropas dispatch().
Om en subklass av View definierar asynkrona (async def) metodhanterare, kommer as_view() att markera den returnerade anropbara funktionen som en coroutine-funktion. Ett ImproperlyConfigured undantag kommer att uppstå om både asynkrona (async def) och synkrona (def) hanterare är definierade på en enda view-klass.
Utför initialisering av nyckelvyn före dispatch().
Tilldelar HttpRequest till vyns request-attribut, och alla positionella och/eller nyckelordsargument fångade från URL-mönstret till args- respektive kwargs-attributen.
Om du åsidosätter den här metoden måste du anropa super().
View-delen av vyn - den metod som tar emot ett request-argument plus argument och returnerar ett HTTP-svar.
Standardimplementeringen inspekterar HTTP-metoden och försöker delegera till en metod som matchar HTTP-metoden; en GET kommer att delegeras till get(), en POST till post(), och så vidare.
Som standard kommer en HEAD-förfrågan att delegeras till get(). Om du behöver hantera HEAD-förfrågningar på ett annat sätt än GET, kan du åsidosätta head()-metoden. Se Stöd för andra HTTP-metoder för ett exempel.
Om vyn anropades med en HTTP-metod som den inte stöder, anropas den här metoden i stället.
\nStandardimplementeringen returnerar HttpResponseNotAllowed med en lista över tillåtna metoder i klartext.
Hanterar svar på förfrågningar om HTTP-verbet OPTIONS. Returnerar ett svar med rubriken Allow som innehåller en lista över vyns tillåtna HTTP-metodnamn.
Om de andra HTTP-metodhanterarna i klassen är asynkrona (async def) kommer svaret att paketeras i en coroutine-funktion för användning med await.
TemplateViewLink to this heading#Renderar en given mall med kontexten som innehåller parametrar som fångas upp i URL:en.
\nAncestors (MRO)
\nDenna vy ärver metoder och attribut från följande vyer:
\nFlödesschema för metod
\n\nExempel på views.py:
\nfrom django.views.generic.base import TemplateView\n\nfrom articles.models import Article\n\n\nclass HomePageView(TemplateView):\n template_name = "home.html"\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context["latest_articles"] = Article.objects.all()[:5]\n return context\nExempel urls.py:
\nfrom django.urls import path\n\nfrom myapp.views import HomePageView\n\nurlpatterns = [\n path("", HomePageView.as_view(), name="home"),\n]\nKontext
\nFylls på (genom ContextMixin) med nyckelordsargumenten som fångats från URL-mönstret som serverade vyn.
Du kan också lägga till kontext med hjälp av extra_context nyckelordsargument för as_view().
RedirectViewLink to this heading#Omdirigeringar till en viss URL.
\nDen angivna URL:en kan innehålla strängformatering i ordboksstil, som interpoleras mot de parametrar som fångas upp i URL:en. Eftersom nyckelordsinterpolering alltid görs (även om inga argument skickas in), måste alla "%"-tecken i webbadressen skrivas som "%%" så att Python konverterar dem till ett enda procenttecken vid utmatning.
Om den angivna URL:en är None kommer Django att returnera en HttpResponseGone (410).
Ancestors (MRO)
\nDenna vy ärver metoder och attribut från följande vy:
\n\nFlödesschema för metod
\n\nExempel på views.py:
\nfrom django.shortcuts import get_object_or_404\nfrom django.views.generic.base import RedirectView\n\nfrom articles.models import Article\n\n\nclass ArticleCounterRedirectView(RedirectView):\n permanent = False\n query_string = True\n pattern_name = "article-detail"\n\n def get_redirect_url(self, *args, **kwargs):\n article = get_object_or_404(Article, pk=kwargs["pk"])\n article.update_counter()\n return super().get_redirect_url(*args, **kwargs)\nExempel urls.py:
\nfrom django.urls import path\nfrom django.views.generic.base import RedirectView\n\nfrom article.views import ArticleCounterRedirectView, ArticleDetailView\n\nurlpatterns = [\n path(\n "counter/<int:pk>/",\n ArticleCounterRedirectView.as_view(),\n name="article-counter",\n ),\n path("details/<int:pk>/", ArticleDetailView.as_view(), name="article-detail"),\n path(\n "go-to-django/",\n RedirectView.as_view(url="https://www.djangoproject.com/"),\n name="go-to-django",\n ),\n]\nAttribut
\nURL:en som ska omdirigeras till, som en sträng. Eller None för att skapa ett 410 (Gone) HTTP-fel.
Namnet på det URL-mönster som ska omdirigeras till. Omdirigeringen görs med samma args och kwargs som skickas in för den här vyn.
\nOm omdirigeringen ska vara permanent. Den enda skillnaden här är den HTTP-statuskod som returneras. Om True används statuskod 301 för omdirigeringen. Om False används statuskod 302 för omdirigeringen. Som standard är permanent False.
Om GET-frågesträngen ska skickas vidare till den nya platsen. Om True, läggs frågesträngen till i URL:en. Om False, kasseras frågesträngen. Som standard är query_string False.
Metoder
\nSkapar mål-URL:en för omdirigering.
\nArgumenten args och kwargs är positions- respektive nyckelordsargument :ref:` som hämtats från URL-mönstret <how-django-processes-a-request>`.
Standardimplementeringen använder url som en startsträng och expanderar % namngivna parametrar i den strängen med hjälp av de namngivna grupper som fångas upp i URL:en.
Om url inte anges försöker get_redirect_url() att vända pattern_name med hjälp av det som fångades upp i URL:en (både namngivna och icke namngivna grupper används).
Om det begärs av query_string, kommer den också att lägga till frågesträngen till den genererade URL:en. Underklasser kan implementera vilket beteende de vill, så länge som metoden returnerar en URL-sträng som är redo för omdirigering.