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 # ...\nSimilarly, Django has a view to handle 400 Bad Request errors.
\nThis view either produces a ”Bad Request” message or loads and renders the\ntemplate 400.html if you created it in your root template directory.\nIt returns with status code 400 indicating that the error condition was the\nresult of a client operation. By default, nothing related to the exception that\ntriggered the view is passed to the template context, as the exception message\nmight contain sensitive information like filesystem paths.
django.views.defaults.bad_request is triggered by a\nBadRequest exception. Also, when a\nSuspiciousOperation is raised in Django,\nit may be handled by a component of Django (for example resetting the session\ndata). If not specifically handled, Django will consider the current request a\n’bad request’ instead of a server error, and handle it with bad_request.
bad_request-vyer används också bara när DEBUG är False.