A view function, or view for short, is simply a Python function that takes a\nWeb request and returns a Web response. This response can be the HTML contents\nof a Web page, or a redirect, or a 404 error, or an XML document, or an image .\n. . or anything, really. The view itself contains whatever arbitrary logic is\nnecessary to return that response. This code can live anywhere you want, as long\nas it’s on your Python path. There’s no other requirement–no „magic,” so to\nspeak. For the sake of putting the code somewhere, the convention is to\nput views in a file called views.py, placed in your project or\napplication directory.
Here’s a view that returns the current date and time, as an HTML document:
\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)\nLet’s step through this code one line at a time:
\nFirst, we import the class HttpResponse from the\ndjango.http module, along with Python’s datetime library.
Next, we define a function called current_datetime. This is the view\nfunction. Each view function takes an HttpRequest\nobject as its first parameter, which is typically named request.
Note that the name of the view function doesn’t matter; it doesn’t have to\nbe named in a certain way in order for Django to recognize it. We’re\ncalling it current_datetime here, because that name clearly indicates\nwhat it does.
The view returns an HttpResponse object that\ncontains the generated response. Each view function is responsible for\nreturning an HttpResponse object. (There are\nexceptions, but we’ll get to those later.)
So, to recap, this view function returns an HTML page that includes the current\ndate and time. To display this view at a particular URL, you’ll need to create a\nURLconf; see URL dispatcher for instructions.
\nReturning HTTP error codes in Django is easy. There are subclasses of\nHttpResponse for a number of common HTTP status codes\nother than 200 (which means „OK”). You can find the full list of available\nsubclasses in the request/response\ndocumentation. Just return an instance of one of those subclasses instead of\na normal HttpResponse in order to signify an error. For\nexample:
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>')\nThere isn’t a specialized subclass for every possible HTTP response code,\nsince many of them aren’t going to be that common. However, as documented in\nthe HttpResponse documentation, you can also pass the\nHTTP status code into the constructor for HttpResponse\nto create a return class for any status code you like. For example:
from django.http import HttpResponse\n\ndef my_view(request):\n # ...\n\n # Return a "created" (201) response code.\n return HttpResponse(status=201)\nBecause 404 errors are by far the most common HTTP error, there’s an easier way\nto handle those errors.
\nHttp404 exceptionLink to this heading#When you return an error such as HttpResponseNotFound,\nyou’re responsible for defining the HTML of the resulting error page:
return HttpResponseNotFound('<h1>Page not found</h1>')\nFor convenience, and because it’s a good idea to have a consistent 404 error page\nacross your site, Django provides an Http404 exception. If you raise\nHttp404 at any point in a view function, Django will catch it and return the\nstandard error page for your application, along with an HTTP error code 404.
Example usage:
\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})\nIn order to show customized HTML when Django returns a 404, you can create an\nHTML template named 404.html and place it in the top level of your\ntemplate tree. This template will then be served when DEBUG is set\nto False.
When DEBUG is True, you can provide a message to Http404 and\nit will appear in the standard 404 debug template. Use these messages for\ndebugging purposes; they generally aren’t suitable for use in a production 404\ntemplate.
The default error views in Django should suffice for most Web applications,\nbut can easily be overridden if you need any custom behavior. Simply specify\nthe handlers as seen below in your URLconf (setting them anywhere else will\nhave no effect).
\nThe page_not_found() view is overridden by\nhandler404:
handler404 = 'mysite.views.my_custom_page_not_found_view'\nThe server_error() view is overridden by\nhandler500:
handler500 = 'mysite.views.my_custom_error_view'\nThe permission_denied() view is overridden by\nhandler403:
handler403 = 'mysite.views.my_custom_permission_denied_view'\nThe bad_request() view is overridden by\nhandler400:
handler400 = 'mysite.views.my_custom_bad_request_view'\nTo test the response of a custom error handler, raise the appropriate exception\nin a test view. For example:
\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