--- title: "Inbyggda vyer" version: 5.2 locale: sv source: https://docs.djangoproject.com/sv/5.2/ref/views/ canonical: https://djangodocs.dev/sv/5.2/ref/views/ --- # Inbyggda vyer Flera av Djangos inbyggda vyer finns dokumenterade i [Skriva synpunkter](/sv/5.2/topics/http/views/) 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()`](#django.views.static.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`](/sv/5.2/ref/settings/#std-setting-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`](/sv/5.2/ref/settings/#std-setting-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.*)$", serve, { "document_root": settings.MEDIA_ROOT, }, ), ] ``` Observera att utdraget förutsätter att din [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-MEDIA_URL) har ett värde på `'media/'`. Detta kommer att anropa vyn [`serve()`](#django.views.static.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()`](/sv/5.2/ref/urls/#django.conf.urls.static.static) som tar som parametrar prefixet som [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-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](/sv/5.2/topics/http/views/#customizing-error-views). ### 404-vyn (sidan hittades inte) #### `defaults.page_not_found(request, exception, template_name='404.html')` När du använder [`Http404`](/sv/5.2/topics/http/views/#django.http.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()`](#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`](/sv/5.2/ref/templates/api/#django.template.RequestContext) och kommer att ha tillgång till variabler som tillhandahålls av dina mallkontextprocessorer (t.ex. `MEDIA_URL`). - Om [`DEBUG`](/sv/5.2/ref/settings/#std-setting-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`](/sv/5.2/ref/settings/#std-setting-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**](https://datatracker.ietf.org/doc/html/rfc9110.html#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`](/sv/5.2/ref/exceptions/#django.core.exceptions.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')` När en [`SuspiciousOperation`](/sv/5.2/ref/exceptions/#django.core.exceptions.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`](/sv/5.2/ref/settings/#std-setting-DEBUG) är `False`.