Flera av Djangos inbyggda vyer finns dokumenterade i Skriva synpunkter samt på andra ställen i dokumentationen.
\nDet kan finnas andra filer än ditt projekts statiska tillgångar som du, för enkelhetens skull, vill att Django ska servera åt dig i lokal utveckling. Vyn serve() kan användas för att servera vilken katalog som helst som du ger den. (Den här vyn är inte härdad för produktionsanvändning och bör endast användas som ett utvecklingshjälpmedel; du bör servera dessa filer i produktion med hjälp av en riktig front-end webbserver).
Det mest troliga exemplet är användaruppladdat innehåll i MEDIA_ROOT. django.contrib.staticfiles är avsedd för statiska tillgångar och har ingen inbyggd hantering för användaruppladdade filer, men du kan få Django att servera din MEDIA_ROOT genom att lägga till något liknande detta till din URLconf:
from django.conf import settings\nfrom django.urls import re_path\nfrom django.views.static import serve\n\n# ... the rest of your URLconf goes here ...\n\nif settings.DEBUG:\n urlpatterns += [\n re_path(\n r"^media/(?P<path>.*)$",\n serve,\n {\n "document_root": settings.MEDIA_ROOT,\n },\n ),\n ]\nObservera att utdraget förutsätter att din MEDIA_URL har ett värde på 'media/'. Detta kommer att anropa vyn serve() och skicka in sökvägen från URLconf och den (obligatoriska) parametern document_root.
Eftersom det kan bli lite besvärligt att definiera detta URL-mönster, levereras Django med en liten URL-hjälpfunktion static() som tar som parametrar prefixet som MEDIA_URL och en prickad sökväg till en vy, till exempel 'django.views.static.serve'. Alla andra funktionsparametrar kommer att skickas transparent till vyn.
Django levereras med några vyer som standard för hantering av HTTP-fel. För att åsidosätta dessa med dina egna anpassade vyer, se Anpassa felvyer.
\nNär du använder Http404 från en vy, laddar Django en speciell vy som är avsedd för att hantera 404-fel. Som standard är det vyn django.views.defaults.page_not_found(), som antingen producerar ett ”Not Found”-meddelande eller laddar och renderar mallen 404.html om du skapade den i din rotmallkatalog.
Standardvyn 404 skickar två variabler till mallen: request_path, som är den URL som resulterade i felet, och exception, som är en användbar representation av det undantag som utlöste vyn (t.ex. innehåller alla meddelanden som skickas till en specifik Http404-instans).
Tre saker att notera om 404-vyer:
\n404-vyn anropas också om Django inte hittar någon matchning efter att ha kontrollerat alla reguljära uttryck i URLconf.
404-vyn får en RequestContext och kommer att ha tillgång till variabler som tillhandahålls av dina mallkontextprocessorer (t.ex. MEDIA_URL).
Om DEBUG är inställd på True (i din inställningsmodul), kommer 404-vyn aldrig att användas och URLconf kommer att visas i stället, med viss felsökningsinformation.
På samma sätt utför Django specialfallbeteende i händelse av körtidsfel i visningskoden. Om en vy resulterar i ett undantag kommer Django som standard att anropa vyn django.views.defaults.server_error, som antingen producerar ett ”Server Error”-meddelande eller laddar och renderar mallen 500.html om du skapade den i din rotmallkatalog.
Standardvyn 500 skickar inga variabler till mallen 500.html och återges med en tom Context för att minska risken för ytterligare fel.
Om DEBUG är satt till True (i din inställningsmodul), kommer din 500-vy aldrig att användas och traceback visas istället, med viss debuginformation.
På samma sätt som 404- och 500-vyerna har Django en vy för att hantera 403 Forbidden-fel. Om en vy resulterar i ett 403-undantag kommer Django som standard att anropa vyn django.views.defaults.permission_denied.
Den här vyn laddar och renderar mallen 403.html i din rotmallkatalog, eller om den här filen inte finns, visar den istället texten ”403 Forbidden”, enligt RFC 9110 Section 15.5.4 (HTTP 1.1-specifikationen). Mallkontexten innehåller exception, som är strängrepresentationen av det undantag som utlöste vyn.
django.views.defaults.permission_denied utlöses av ett PermissionDenied undantag. För att neka åtkomst i en vy kan du använda kod som denna:
from django.core.exceptions import PermissionDenied\n\n\ndef edit(request, pk):\n if not request.user.is_staff:\n raise PermissionDenied\n # ...\nNär en SuspiciousOperation uppstår i Django kan den hanteras av en komponent i Django (till exempel återställning av sessionsdata). Om det inte hanteras specifikt kommer Django att betrakta den aktuella begäran som en ”dålig begäran” istället för ett serverfel.
django.views.defaults.bad_request, är annars mycket lik vyn server_error, men returnerar med statuskoden 400 som indikerar att feltillståndet var resultatet av en klientoperation. Som standard skickas ingenting som är relaterat till det undantag som utlöste vyn till mallkontexten, eftersom undantagsmeddelandet kan innehålla känslig information som filsystemssökvägar.
bad_request-vyer används också bara när DEBUG är False.