En view är en callable som tar emot en request och returnerar ett svar. Detta kan vara mer än bara en funktion, och Django ger ett exempel på några klasser som kan användas som vyer. Dessa gör att du kan strukturera dina vyer och återanvända kod genom att utnyttja arv och mixins. Det finns också några generiska vyer för uppgifter som vi kommer till senare, men du kanske vill utforma din egen struktur av återanvändbara vyer som passar ditt användningsfall. För fullständiga detaljer, se class-based views reference documentation.
\nDjango tillhandahåller basvyklasser som passar ett brett spektrum av applikationer. Alla vyer ärver från View-klassen, som hanterar länkning av vyn till webbadresserna, HTTP-metodutskick och andra vanliga funktioner. RedirectView tillhandahåller en HTTP-omdirigering, och TemplateView utökar basklassen så att den också kan rendera en mall.
Det mest direkta sättet att använda generiska vyer är att skapa dem direkt i din URLconf. Om du bara ändrar några få attribut på en klassbaserad vy kan du skicka dem till as_view() metodanropet själv:
from django.urls import path\nfrom django.views.generic import TemplateView\n\nurlpatterns = [\n path("about/", TemplateView.as_view(template_name="about.html")),\n]\nEventuella argument som skickas till as_view() kommer att åsidosätta attribut som ställts in på klassen. I det här exemplet ställer vi in template_name på TemplateView. Ett liknande åsidosättningsmönster kan användas för attributet url på RedirectView.
Det andra, mer kraftfulla sättet att använda generiska vyer är att ärva från en befintlig vy och åsidosätta attribut (t.ex. template_name) eller metoder (t.ex. get_context_data) i din underklass för att tillhandahålla nya värden eller metoder. Tänk till exempel på en vy som bara visar en mall, about.html. Django har en generisk vy för att göra detta - TemplateView - så vi kan subklassa den och åsidosätta mallnamnet:
# some_app/views.py\nfrom django.views.generic import TemplateView\n\n\nclass AboutView(TemplateView):\n template_name = "about.html"\nSedan måste vi lägga till den här nya vyn i vår URLconf. TemplateView är en klass, inte en funktion, så vi pekar URL:en till klassmetoden as_view() istället, som ger en funktionsliknande ingång till klassbaserade vyer:
# urls.py\nfrom django.urls import path\nfrom some_app.views import AboutView\n\nurlpatterns = [\n path("about/", AboutView.as_view()),\n]\nMer information om hur du använder de inbyggda generiska vyerna finns i nästa ämne i generiska klassbaserade vyer.
\nAnta att någon vill komma åt vårt bokbibliotek via HTTP med hjälp av vyerna som ett API. API-klienten skulle ansluta då och då och ladda ner bokdata för de böcker som publicerats sedan förra besöket. Men om inga nya böcker har dykt upp sedan dess är det slöseri med CPU-tid och bandbredd att hämta böckerna från databasen, rendera ett fullständigt svar och skicka det till klienten. Det kan vara att föredra att fråga API:et när den senaste boken publicerades.
\nVi mappar URL:en till boklistans vy i URLconf:
\nfrom django.urls import path\nfrom books.views import BookListView\n\nurlpatterns = [\n path("books/", BookListView.as_view()),\n]\nOch utsikten:
\nfrom django.http import HttpResponse\nfrom django.views.generic import ListView\nfrom books.models import Book\n\n\nclass BookListView(ListView):\n model = Book\n\n def head(self, *args, **kwargs):\n last_book = self.get_queryset().latest("publication_date")\n response = HttpResponse(\n # RFC 1123 date format.\n headers={\n "Last-Modified": last_book.publication_date.strftime(\n "%a, %d %b %Y %H:%M:%S GMT"\n )\n },\n )\n return response\nOm vyn nås med en GET-begäran returneras en objektlista i svaret (med mallen book_list.html). Men om klienten skickar en HEAD-begäran har svaret en tom brödtext och headern Last-Modified anger när den senaste boken publicerades. Baserat på den informationen kan klienten välja att hämta hela objektlistan eller låta bli.
Förutom de synkrona (def) metodhanterare som redan visats, kan View subklasser definiera asynkrona (async def) metodhanterare för att utnyttja asynkron kod med hjälp av await:
import asyncio\nfrom django.http import HttpResponse\nfrom django.views import View\n\n\nclass AsyncView(View):\n async def get(self, request, *args, **kwargs):\n # Perform io-blocking view logic using await, sleep for example.\n await asyncio.sleep(1)\n return HttpResponse("Hello async world!")\nInom en och samma view-klass måste alla användardefinierade metodhanterare vara antingen synkrona, med def, eller asynkrona, med async def. Ett ImproperlyConfigured undantag kommer att uppstå i as_view() om def och async def deklarationer blandas.
Django kommer automatiskt att upptäcka asynkrona vyer och köra dem i ett asynkront sammanhang. Du kan läsa mer om Djangos asynkrona stöd, och hur du bäst använder asynkrona vyer, i Asynkront stöd.
\n