Une fonction de vue, ou vue pour faire simple, est une simple fonction Python acceptant une requête Web et renvoyant une réponse Web. Cette réponse peut contenir le contenu HTML d’une page Web, une redirection, une erreur 404, un document XML, une image… ou vraiment n’importe quoi d’autre. La vue elle-même contient la logique nécessaire pour renvoyer une réponse. Ce code peut se trouver à l’emplacement de votre choix, pour autant qu’il soit dans le chemin Python. Il n’y a pas d’autres exigences, pas de « magie » comme on dit. Mais comme il faut bien mettre ce code quelque part, la convention est de placer les vues dans un fichier nommé views.py se trouvant dans un projet ou un répertoire d’application.
Voici une vue qui renvoie l’heure et la date actuelle, sous forme d’un document HTML :
\nfrom django.http import HttpResponse\nimport datetime\n\ndef current_datetime(request):\n now = datetime.datetime.now()\n html = "<html><body>It is now %s.</body></html>" % now\n return HttpResponse(html)\nPassons ce code en revue ligne par ligne :
\nNous importons d’abord la classe HttpResponse à partir du module django.http, ainsi que la bibliothèque datetime de Python.
Puis, nous définissons une fonction nommée current_datetime. C’est la fonction de vue. Chaque fonction de vue accepte un objet HttpRequest comme premier paramètre, typiquement nommé request.
Remarquez que le nom de la fonction de vue n’a aucune importance ; la vue ne doit pas être nommée d’une certaine manière pour que Django puisse la reconnaître. Nous l’avons appelée current_datetime ici car ce nom indique clairement ce qu’elle fait.
La vue renvoie un objet HttpResponse contenant la réponse générée. Chaque fonction de vue est chargée de renvoyer un objet HttpResponse (il y a des exceptions, mais nous les aborderons plus tard).
Ainsi, pour résumer, cette fonction de vue renvoie une page HTML contenant la date et l’heure actuelles. Pour afficher cette vue avec une URL particulière, il est nécessaire de créer une configuration d’URL. Voir Distribution des URL pour les instructions.
\nLe renvoi de codes d’erreur HTTP est simple dans Django. Il existe des sous-classes de HttpResponse pour tous les codes de statut HTTP les plus courants autres que 200 (qui signifie « OK »). La liste complète des sous-classes disponibles se trouve dans la documentation des requêtes/réponses. Il suffit de renvoyer une instance de l’une de ces sous-classes au lieu d’une réponse HttpResponse normale afin de signaler une erreur. Par exemple :
from django.http import HttpResponse, HttpResponseNotFound\n\ndef my_view(request):\n # ...\n if foo:\n return HttpResponseNotFound('<h1>Page not found</h1>')\n else:\n return HttpResponse('<h1>Page was found</h1>')\nIl n’existe pas de sous-classe spécialisée pour chaque code de réponse HTTP possible, car la plupart ne se rencontrent que très rarement. Cependant, comme décrit dans la documentation de HttpResponse, il est aussi possible de transmettre le code de statut HTTP au constructeur de HttpResponse pour créer une classe à renvoyer pour n’importe quel code de statut. Par exemple :
from django.http import HttpResponse\n\ndef my_view(request):\n # ...\n\n # Return a "created" (201) response code.\n return HttpResponse(status=201)\nComme les erreurs 404 sont de loin les erreurs HTTP les plus fréquentes, il existe une façon simplifiée de les traiter.
\nHttp404Lien vers cette rubrique#Lorsque vous renvoyez une erreur telle que HttpResponseNotFound, vous êtes chargé de définir le code HTML de la page d’erreur résultante :
return HttpResponseNotFound('<h1>Page not found</h1>')\nPar commodité et parce qu’il est conseillé d’avoir une page d’erreur 404 cohérente pour tout un site, Django fournit une exception Http404. Si vous générez Http404 quelque part dans une fonction de vue, Django l’intercepte et renvoie la page d’erreur standard de l’application, en compagnie du code d’erreur HTTP 404.
Exemple d’utilisation :
\nfrom django.http import Http404\nfrom django.shortcuts import render\nfrom polls.models import Poll\n\ndef detail(request, poll_id):\n try:\n p = Poll.objects.get(pk=poll_id)\n except Poll.DoesNotExist:\n raise Http404("Poll does not exist")\n return render(request, 'polls/detail.html', {'poll': p})\nAfin de pouvoir afficher du HTML personnalisé lorsque Django répond avec une page 404, il est possible de créer un gabarit HTML nommé 404.html et de le placer au premier niveau de l’arborescence des gabarits. Ce gabarit sera alors utilisé lorsque le réglage DEBUG est défini à False.
Lorsque DEBUG vaut True, vous pouvez fournir un message à Http404 et il apparaîtra dans le gabarit 404 standard de débogage. Utilisez ces messages à des fins de débogage ; ils ne sont généralement pas adaptés aux gabarits 404 de production.
Les vues d’erreur par défaut de Django conviennent bien à la majorité des applications Web, mais elles peuvent aisément être surchargées en cas de besoin particulier. Il suffit de redéfinir les gestionnaires correspondants comme démontré ci-dessous, dans la configuration d’URL racine (leur définition à tout autre endroit est sans effet).
\nLa vue page_not_found() est surchargée par handler404:
handler404 = 'mysite.views.my_custom_page_not_found_view'\nLa vue server_error() est surchargée par handler500:
handler500 = 'mysite.views.my_custom_error_view'\nLa vue permission_denied() est surchargée par handler403:
handler403 = 'mysite.views.my_custom_permission_denied_view'\nLa vue bad_request() est surchargée par handler400:
handler400 = 'mysite.views.my_custom_bad_request_view'\nPour tester la réponse d’un gestionnaire d’erreur personnalisé, générez l’exception appropriée dans une vue de test. Par exemple
\nfrom django.core.exceptions import PermissionDenied\nfrom django.http import HttpResponse\nfrom django.test import SimpleTestCase, override_settings\nfrom django.urls import path\n\n\ndef response_error_handler(request, exception=None):\n return HttpResponse('Error handler content', status=403)\n\n\ndef permission_denied_view(request):\n raise PermissionDenied\n\n\nurlpatterns = [\n path('403/', permission_denied_view),\n]\n\nhandler403 = response_error_handler\n\n\n# ROOT_URLCONF must specify the module that contains handler403 = ...\n@override_settings(ROOT_URLCONF=__name__)\nclass CustomErrorHandlerTests(SimpleTestCase):\n\n def test_handler_renders_template_response(self):\n response = self.client.get('/403/')\n # Make assertions on the response here. For example:\n self.assertContains(response, 'Error handler content', status_code=403)\n