--- title: "Vues intégrées" version: 3.2 locale: fr source: https://docs.djangoproject.com/fr/3.2/ref/views/ canonical: https://djangodocs.dev/fr/3.2/ref/views/ --- # Vues intégrées Plusieurs vues intégrées de Django sont documentées dans [Écriture de vues](/fr/3.2/topics/http/views/) 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()`](#django.views.static.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`](/fr/3.2/ref/settings/#std-setting-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`](/fr/3.2/ref/settings/#std-setting-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.*)$', serve, { 'document_root': settings.MEDIA_ROOT, }), ] ``` Notez que cet extrait suppose que votre réglage [`MEDIA_URL`](/fr/3.2/ref/settings/#std-setting-MEDIA_URL) contient la valeur `'/media/'`. Ce code appelle la vue [`serve()`](#django.views.static.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()`](/fr/3.2/ref/urls/#django.conf.urls.static.static), qui accepte en paramètre le préfixe (tel que [`MEDIA_URL`](/fr/3.2/ref/settings/#std-setting-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](/fr/3.2/topics/http/views/#customizing-error-views). ### 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`](/fr/3.2/topics/http/views/#django.http.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()`](#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`](/fr/3.2/ref/templates/api/#django.template.RequestContext) et peut accéder aux variables produites par les processeurs de contexte de gabarit (par ex. `MEDIA_URL`). - Si [`DEBUG`](/fr/3.2/ref/settings/#std-setting-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`](/fr/3.2/ref/settings/#std-setting-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 7231 Section 6.5.3**](https://datatracker.ietf.org/doc/html/rfc7231.html#section-6.5.3) (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`](/fr/3.2/ref/exceptions/#django.core.exceptions.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')` Lorsqu’une exception [`SuspiciousOperation`](/fr/3.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) est générée dans Django, elle peut être traitée par un composant de Django (par exemple en réinitialisant les données de session). Lorsque ce n’est pas le cas, Django considère que la requête actuelle est une « mauvaise requête », au lieu de produire une erreur de serveur. `django.views.defaults.bad_request` est globalement très semblable à la vue `server_error`, mais renvoie un code de statut 400 indiquant que la condition d’erreur est le résultat d’une opération du client. Par défaut, aucun élément de l’exception qui a déclenché la vue n’est transmis au contexte du gabarit, dans la mesure où le message de l’exception pourrait contenir des informations sensibles telles que des chemins de système de fichiers. Les vues `bad_request` ne sont également utilisées que lorsque [`DEBUG`](/fr/3.2/ref/settings/#std-setting-DEBUG) vaut `False`.