Plusieurs vues intégrées de Django sont documentées dans Écriture de vues ainsi qu’à divers autres endroits de la documentation.
\nIl 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\nfrom django.urls import re_path\nfrom django.views.static import serve\n\n# ... the rest of your URLconf goes here ...\n\nif settings.DEBUG:\n urlpatterns += [\n re_path(r'^media/(?P<path>.*)$', serve, {\n 'document_root': settings.MEDIA_ROOT,\n }),\n ]\nNotez 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.
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.
\nLorsque 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é » très simple, 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 :
\nLa 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.
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 » très simple, 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.
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 (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\n\ndef edit(request, pk):\n if not request.user.is_staff:\n raise PermissionDenied\n # ...\nLorsqu’une exception 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 vaut False.