Att skriva webbapplikationer kan vara enformigt, eftersom vi upprepar vissa mönster om och om igen. Django försöker ta bort en del av denna monotoni på modell- och mallnivåerna, men webbutvecklare upplever också denna tristess på vynivån.
\nDjangos generiska vyer utvecklades för att lindra den smärtan. De tar vissa vanliga idiom och mönster som finns i vyutveckling och abstraherar dem så att du snabbt kan skriva vanliga vyer över data utan att behöva skriva för mycket kod.
\nVi kan känna igen vissa vanliga uppgifter, som att visa en lista med objekt, och skriva kod som visar en lista med valfritt objekt. Då kan modellen i fråga skickas som ett extra argument till URLconf.
\nDjango levereras med generiska vyer för att göra följande:
\nVisar list- och detaljsidor för ett enda objekt. Om vi skulle skapa en applikation för att hantera konferenser så skulle en TalkListView och en RegisteredUserListView vara exempel på listvyer. En enskild samtalssida är ett exempel på vad vi kallar en ”detalj”-vy.
Presentera datumbaserade objekt på arkivsidor för år/månad/dag, tillhörande detalj- och ”senaste”-sidor.
Tillåt användare att skapa, uppdatera och ta bort objekt - med eller utan behörighet.
Sammantaget ger dessa vyer gränssnitt för att utföra de vanligaste uppgifterna som utvecklare stöter på.
\nDet råder ingen tvekan om att generiska vyer kan snabba upp utvecklingen avsevärt. I de flesta projekt kommer det dock ett ögonblick när de generiska vyerna inte längre räcker till. Den vanligaste frågan som ställs av nya Django-utvecklare är faktiskt hur man får generiska vyer att hantera ett bredare spektrum av situationer.
\nDetta är en av anledningarna till att generiska vyer fick en ny design i 1.3-versionen - tidigare var de vyfunktioner med en förvirrande mängd alternativ; nu, i stället för att skicka in en stor mängd konfiguration i URLconf, är det rekommenderade sättet att utöka generiska vyer att underklassa dem och åsidosätta deras attribut eller metoder.
\nMed detta sagt har generiska vyer en gräns. Om du har svårt att implementera din vy som en underklass till en generisk vy kan det vara mer effektivt att bara skriva den kod du behöver med hjälp av dina egna klassbaserade eller funktionella vyer.
\nFler exempel på generiska vyer finns i vissa tredjepartsapplikationer, eller så kan du skriva dina egna efter behov.
\nTemplateView är förvisso användbar, men Djangos generiska vyer briljerar verkligen när det gäller att presentera vyer av ditt databasinnehåll. Eftersom det är en så vanlig uppgift kommer Django med en handfull inbyggda generiska vyer för att hjälpa till att generera list- och detaljvyer av objekt.
Låt oss börja med att titta på några exempel på hur man visar en lista med objekt eller ett enskilt objekt.
\nVi kommer att använda dessa modeller:
\n# models.py\nfrom django.db import models\n\n\nclass Publisher(models.Model):\n name = models.CharField(max_length=30)\n address = models.CharField(max_length=50)\n city = models.CharField(max_length=60)\n state_province = models.CharField(max_length=30)\n country = models.CharField(max_length=50)\n website = models.URLField()\n\n class Meta:\n ordering = ["-name"]\n\n def __str__(self):\n return self.name\n\n\nclass Author(models.Model):\n salutation = models.CharField(max_length=10)\n name = models.CharField(max_length=200)\n email = models.EmailField()\n headshot = models.ImageField(upload_to="author_headshots")\n\n def __str__(self):\n return self.name\n\n\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n authors = models.ManyToManyField("Author")\n publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)\n publication_date = models.DateField()\nNu måste vi definiera en vy:
\n# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\n\nclass PublisherListView(ListView):\n model = Publisher\nKoppla slutligen den vyn till dina webbadresser:
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherListView\n\nurlpatterns = [\n path("publishers/", PublisherListView.as_view()),\n]\nDet är all Python-kod vi behöver skriva. Vi behöver dock fortfarande skriva en mall. Vi kan uttryckligen berätta för vyn vilken mall som ska användas genom att lägga till ett template_name-attribut till vyn, men i avsaknad av en uttrycklig mall kommer Django att härleda en från objektets namn. I det här fallet kommer den härledda mallen att vara "books/publisher_list.html" - ”books”-delen kommer från namnet på appen som definierar modellen, medan ”publisher”-biten är den gemena versionen av modellens namn.
Denna mall kommer att renderas mot ett sammanhang som innehåller en variabel som heter object_list som innehåller alla utgivarobjekt. En mall kan se ut så här:
{% extends "base.html" %}\n\n{% block content %}\n <h2>Publishers</h2>\n <ul>\n {% for publisher in object_list %}\n <li>{{ publisher.name }}</li>\n {% endfor %}\n </ul>\n{% endblock %}\nDet är verkligen allt det är. Alla de häftiga funktionerna i generiska vyer kommer från att ändra de attribut som ställts in på den generiska vyn. I generic views reference dokumenteras alla generiska vyer och deras alternativ i detalj; resten av det här dokumentet kommer att behandla några av de vanligaste sätten du kan anpassa och utöka generiska vyer.
\nDu kanske har lagt märke till att vår mall för förlagslistan lagrar alla förlag i en variabel med namnet ”object_list”. Även om detta fungerar bra är det inte så ”vänligt” mot mallförfattare: de måste ”bara veta” att de har att göra med utgivare här.
\nTja, om du har att göra med ett modellobjekt är detta redan gjort åt dig. När du har att göra med ett objekt eller en queryset kan Django fylla i kontexten med den gemena versionen av modellklassens namn. Detta tillhandahålls utöver standardposten object_list, men innehåller exakt samma data, dvs. publisher_list.
Om detta fortfarande inte är en bra matchning kan du manuellt ställa in namnet på kontextvariabeln. Attributet context_object_name på en generisk vy anger vilken kontextvariabel som ska användas:
# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\n\nclass PublisherListView(ListView):\n model = Publisher\n context_object_name = "my_favorite_publishers"\nAtt tillhandahålla ett användbart context_object_name är alltid en bra idé. Dina kollegor som designar mallar kommer att tacka dig.
Ofta behöver du presentera lite extra information utöver den som tillhandahålls av den generiska vyn. Tänk till exempel på att visa en lista över alla böcker på varje förlags detaljsida. Den generiska vyn DetailView ger utgivaren till sammanhanget, men hur får vi ytterligare information i den mallen?
Svaret är att underordna DetailView och tillhandahålla din egen implementering av metoden get_context_data. Standardimplementeringen lägger till objektet som visas i mallen, men du kan åsidosätta den för att skicka mer:
from django.views.generic import DetailView\nfrom books.models import Book, Publisher\n\n\nclass PublisherDetailView(DetailView):\n model = Publisher\n\n def get_context_data(self, **kwargs):\n # Call the base implementation first to get a context\n context = super().get_context_data(**kwargs)\n # Add in a QuerySet of all the books\n context["book_list"] = Book.objects.all()\n return context\nLåt oss nu ta en närmare titt på argumentet model som vi har använt hela tiden. Argumentet model, som anger den databasmodell som vyn ska arbeta med, är tillgängligt för alla generiska vyer som arbetar med ett enda objekt eller en samling objekt. Argumentet model är dock inte det enda sättet att ange de objekt som vyn ska arbeta med - du kan också ange listan över objekt med argumentet queryset:
from django.views.generic import DetailView\nfrom books.models import Publisher\n\n\nclass PublisherDetailView(DetailView):\n context_object_name = "publisher"\n queryset = Publisher.objects.all()\nAtt ange model = Publisher är en förkortning för att säga queryset = Publisher.objects.all(). Men genom att använda queryset för att definiera en filtrerad lista över objekt kan du vara mer specifik om de objekt som kommer att synas i vyn (se Göra förfrågningar för mer information om QuerySet-objekt, och se class-based views reference för fullständiga detaljer).
För att ta ett exempel kanske vi vill sortera en lista med böcker efter utgivningsdatum, med den senaste först:
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\n\nclass BookListView(ListView):\n queryset = Book.objects.order_by("-publication_date")\n context_object_name = "book_list"\nDet är ett ganska minimalt exempel, men det illustrerar idén på ett bra sätt. Du vill vanligtvis göra mer än att bara ordna om objekt. Om du vill presentera en lista över böcker från ett visst förlag kan du använda samma teknik:
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\n\nclass AcmeBookListView(ListView):\n context_object_name = "book_list"\n queryset = Book.objects.filter(publisher__name="ACME Publishing")\n template_name = "books/acme_list.html"\nLägg märke till att vi tillsammans med ett filtrerat queryset också använder ett anpassat mallnamn. Om vi inte gjorde det skulle den generiska vyn använda samma mall som ”vanilj”-objektlistan, vilket kanske inte är vad vi vill.
Observera också att det här inte är ett särskilt elegant sätt att göra förlagsspecifika böcker. Om vi vill lägga till ytterligare en förlagssida skulle vi behöva ytterligare en handfull rader i URLconf, och mer än ett fåtal förlag skulle bli orimliga. Vi tar itu med det här problemet i nästa avsnitt.
\n\nAnother common need is to filter down the objects given in a list page by some\nkey in the URL. Earlier we hardcoded the publisher’s name in the URLconf, but\nwhat if we wanted to write a view that displayed all the books by some\narbitrary publisher?
\nPraktiskt nog har ListView en get_queryset()-metod som vi kan åsidosätta. Som standard returnerar den värdet på attributet queryset, men vi kan använda det för att lägga till mer logik.
Den viktigaste delen för att få detta att fungera är att när klassbaserade vyer anropas lagras olika användbara saker på self; förutom begäran (self.request) inkluderar detta de positionella (self.args) och namnbaserade (self.kwargs) argumenten som fångas enligt URLconf.
Här har vi en URLconf med en enda fångad grupp:
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherBookListView\n\nurlpatterns = [\n path("books/<publisher>/", PublisherBookListView.as_view()),\n]\nNu ska vi skriva själva vyn PublisherBookListView:
# views.py\nfrom django.shortcuts import get_object_or_404\nfrom django.views.generic import ListView\nfrom books.models import Book, Publisher\n\n\nclass PublisherBookListView(ListView):\n template_name = "books/books_by_publisher.html"\n\n def get_queryset(self):\n self.publisher = get_object_or_404(Publisher, name=self.kwargs["publisher"])\n return Book.objects.filter(publisher=self.publisher)\nAtt använda get_queryset för att lägga till logik i queryset-urvalet är lika bekvämt som det är kraftfullt. Om vi till exempel vill kan vi använda self.request.user för att filtrera med hjälp av den aktuella användaren eller annan mer komplex logik.
Vi kan också lägga till utgivaren i sammanhanget samtidigt, så att vi kan använda den i mallen:
\n# ...\n\n\ndef get_context_data(self, **kwargs):\n # Call the base implementation first to get a context\n context = super().get_context_data(**kwargs)\n # Add in the publisher\n context["publisher"] = self.publisher\n return context\nDet sista vanliga mönstret vi ska titta på innebär att man gör lite extra arbete före eller efter anropet av den generiska vyn.
\nTänk dig att vi hade ett last_accessed fält på vår Author modell som vi använde för att hålla reda på den sista gången någon tittade på den författaren:
# models.py\nfrom django.db import models\n\n\nclass Author(models.Model):\n salutation = models.CharField(max_length=10)\n name = models.CharField(max_length=200)\n email = models.EmailField()\n headshot = models.ImageField(upload_to="author_headshots")\n last_accessed = models.DateTimeField()\nDen generiska klassen DetailView vet ingenting om det här fältet, men återigen kan vi skriva en anpassad vy för att hålla fältet uppdaterat.
Först måste vi lägga till en författardetaljbit i URLconf för att peka på en anpassad vy:
\nfrom django.urls import path\nfrom books.views import AuthorDetailView\n\nurlpatterns = [\n # ...\n path("authors/<int:pk>/", AuthorDetailView.as_view(), name="author-detail"),\n]\nSedan skriver vi vår nya vy – get_object är den metod som hämtar objektet – så vi åsidosätter den och omsluter anropet:
from django.utils import timezone\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\n\nclass AuthorDetailView(DetailView):\n queryset = Author.objects.all()\n\n def get_object(self):\n obj = super().get_object()\n # Record the last accessed date\n obj.last_accessed = timezone.now()\n obj.save()\n return obj\n