# Django 6.0.5 documentation

# 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')

Similarly, Django has a view to handle 400 Bad Request errors.

This view either produces a ”Bad Request” message or loads and renders the template `400.html` if you created it in your root template directory. It returns with status code 400 indicating that the error condition was the result of a client operation. By default, nothing related to the exception that triggered the view is passed to the template context, as the exception message might contain sensitive information like filesystem paths.

`django.views.defaults.bad_request` is triggered by a `BadRequest` exception. Also, when a `SuspiciousOperation` is raised in Django, it may be handled by a component of Django (for example resetting the session data). If not specifically handled, Django will consider the current request a ’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`.