# Documentation Django 6.0.7

# Vues intégrées

Plusieurs vues intégrées de Django sont documentées dans Écriture de vues ainsi qu’à divers autres endroits de la documentation.

## Service des fichiers durant le développement

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

Il est possible que vous souhaitiez que Django serve aussi d’autres fichiers que les fichiers statiques du projet lors de la phase de développement local. La vue `serve()` peut être utilisée pour servir le contenu de n’importe quel répertoire. (Cette vue n’est pas suffisamment robuste pour une utilisation en production et ne devrait être utilisée que pour aider au développement ; ces fichiers devraient être servis en production par un serveur web frontal réel.)

L’exemple le plus probable concerne les fichiers téléversés par les utilisateurs dans `MEDIA_ROOT`. `django.contrib.staticfiles` est prévu pour les fichiers statiques en ne comporte pas de gestion intégrée pour les fichiers téléversés par les utilisateurs, mais vous pouvez demander à Django de servir le contenu de `MEDIA_ROOT` an ajoutant quelque chose comme ceci à votre configuration d’URL :

    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,
                },
            ),
        ]

Notez que cet extrait suppose que votre réglage `MEDIA_URL` contient la valeur `'media/'`. Ce code appelle la vue `serve()` en lui transmettant le chemin capturé par la configuration d’URL et le paramètre (obligatoire) `document_root`.

Comme il peut vite devenir pesant de définir ce motif d’URL, Django est livré avec une petite fonction utilitaire d’URL nommée `static()`, qui accepte en paramètre le préfixe (tel que `MEDIA_URL`) et un chemin vers une vue en syntaxe pointée, tel que `'django.views.static.serve'`. Tout autre paramètre de fonction est transmis à la vue de manière transparente.

## Vues d’erreur

Django est livré avec quelques vues par défaut pour traiter les erreurs HTTP. Pour remplacer celles-ci par vos propres vues personnalisées, consultez Personnalisation des vues d’erreur.

### La vue 404 (page non trouvée)

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

Lorsque vous générez une exception `Http404` à partir d’une vue, Django charge une vue spéciale consacrée au traitement des erreurs 404. Par défaut, il s’agit de la vue `django.views.defaults.page_not_found()` qui produit soit un message « Non trouvé », soit charge et affiche le gabarit `404.html` si celui-ci existe dans le répertoire racine des gabarits.

La vue 404 par défaut va passer deux variables au gabarit : `request_path`, qui est l’URL qui a abouti à l’erreur, et `exception`, qui est une représentation utile de l’exception qui a déclenché la vue (par ex. contenant un éventuel message transmis à une instance `Http404` spécifique).

Trois éléments à signaler à propos des vues 404 :

- La vue 404 est également appelée si Django ne trouve pas de correspondance après avoir vérifié chaque expression régulière dans la configuration d’URL.

- La vue 404 reçoit un objet `RequestContext` et peut accéder aux variables produites par les processeurs de contexte de gabarit (par ex. `MEDIA_URL`).

- Si `DEBUG` est défini à `True` (dans votre module de réglages), la vue 404 ne sera jamais utilisée, mais elle est remplacée par l’affichage de la configuration d’URL ainsi que de certaines informations de débogage.

### La vue 500 (erreur de serveur)

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

De la même façon, Django passe par un comportement d’exception en cas d’erreur d’exécution dans le code d’une vue. Lorsqu’une vue génère une exception, Django appelle par défaut la vue `django.views.defaults.server_error`, qui produit soit un message « Erreur de serveur », soit charge et affiche le gabarit `500.html` si celui-ci existe au premier niveau du répertoire des gabarits.

La vue 500 par défaut ne transmet aucune variable au gabarit `500.html`, celui-ci recevant un context `Context` vide pour minimiser le risque d’erreurs supplémentaires.

Si `DEBUG` est défini à `True` (dans votre module de réglages), la vue 500 ne sera jamais utilisée, mais elle est remplacée par l’affichage de la pile d’appels (« traceback ») ainsi que de certaines informations de débogage.

### La vue 403 (accès interdit ou « HTTP Forbidden »)

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

Dans la même perspective que pour les vues 404 et 500, Django contient une vue pour gérer les erreurs 403 d’accès refusé. Si une vue génère une exception 403, Django appelle par défaut la vue `django.views.defaults.permission_denied`.

Cette vue charge et affiche le gabarit `403.html` se trouvant à la racine du répertoire des gabarits, ou, si ce fichier n’existe pas, affiche le texte « 403 Forbidden » comme le prescrit le RFC 9110 Section 15.5.4 (la spécification HTTP 1.1). Le contexte de gabarit contient `exception` qui est une représentation textuelle de l’expression qui a déclenché la vue.

`django.views.defaults.permission_denied` est provoquée par une exception `PermissionDenied`. Pour refuser l’accès à l’une de vos vues, voici le code pouvant être utilisé :

    from django.core.exceptions import PermissionDenied

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

### La vue 400 (mauvaise requête)

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

Les vues `bad_request` ne sont également utilisées que lorsque `DEBUG` vaut `False`.