Inbyggda vyer

Flera av Djangos inbyggda vyer finns dokumenterade i Skriva synpunkter samt på andra ställen i dokumentationen.

Servering av filer under utveckling

static.serve(request, path, document_root, show_indexes=False)

Det 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
from django.urls import re_path
from django.views.static import serve

# ... the rest of your URLconf goes here ...

if settings.DEBUG:
    urlpatterns += [
        re_path(
            r"^media/(?P<path>.*)$",
            serve,
            {
                "document_root": settings.MEDIA_ROOT,
            },
        ),
    ]

Observera 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.

Visning av fel

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.

404-vyn (sidan hittades inte)

defaults.page_not_found(request, exception, template_name='404.html')

Nä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:

• 404-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.

Vyn 500 (serverfel)

defaults.server_error(request, template_name='500.html')

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.

Vyn 403 (HTTP förbjuden)

defaults.permission_denied(request, exception, template_name='403.html')

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


def edit(request, pk):
    if not request.user.is_staff:
        raise PermissionDenied
    # ...

Vyn 400 (dålig förfrågan)

defaults.bad_request(request, exception, template_name='400.html')

Django har på samma sätt en vy för att hantera fel av typen 400 Bad Request.

Den här vyn visar antingen meddelandet ”Bad Request” eller läser in och återger mallen 400.html om du har skapat den i din rotmallkatalog. Den returnerar statuskoden 400, som anger att feltillståndet orsakades av en klientåtgärd. Som standard skickas inget som rör undantaget som utlöste vyn till mallkontexten, eftersom undantagsmeddelandet kan innehålla känslig information som filsökvägar.

django.views.defaults.bad_request utlöses av undantaget BadRequest. När SuspiciousOperation utlöses i Django kan det dessutom hanteras av en Django-komponent, till exempel genom att sessionsdata återställs. Om det inte hanteras särskilt betraktar Django den aktuella begäran som en ”dålig begäran” i stället för ett serverfel och hanterar den med bad_request.

bad_request-vyer används också bara när DEBUG är False.