PageRenderTime 34ms CodeModel.GetById 18ms RepoModel.GetById 0ms app.codeStats 0ms

Plain Text | 202 lines | 149 code | 53 blank | 0 comment | 0 complexity | 604c36cd43426fcb8dbfc403a9ba7b5c MD5 | raw file
Possible License(s): BSD-3-Clause
  1. =============
  2. Writing views
  3. =============
  4. A view function, or *view* for short, is simply a Python function that takes a
  5. Web request and returns a Web response. This response can be the HTML contents
  6. of a Web page, or a redirect, or a 404 error, or an XML document, or an image .
  7. . . or anything, really. The view itself contains whatever arbitrary logic is
  8. necessary to return that response. This code can live anywhere you want, as long
  9. as it's on your Python path. There's no other requirement--no "magic," so to
  10. speak. For the sake of putting the code *somewhere*, the convention is to
  11. put views in a file called ````, placed in your project or
  12. application directory.
  13. A simple view
  14. =============
  15. Here's a view that returns the current date and time, as an HTML document:
  16. .. code-block:: python
  17. from django.http import HttpResponse
  18. import datetime
  19. def current_datetime(request):
  20. now =
  21. html = "<html><body>It is now %s.</body></html>" % now
  22. return HttpResponse(html)
  23. Let's step through this code one line at a time:
  24. * First, we import the class :class:`~django.http.HttpResponse` from the
  25. :mod:`django.http` module, along with Python's ``datetime`` library.
  26. * Next, we define a function called ``current_datetime``. This is the view
  27. function. Each view function takes an :class:`~django.http.HttpRequest`
  28. object as its first parameter, which is typically named ``request``.
  29. Note that the name of the view function doesn't matter; it doesn't have to
  30. be named in a certain way in order for Django to recognize it. We're
  31. calling it ``current_datetime`` here, because that name clearly indicates
  32. what it does.
  33. * The view returns an :class:`~django.http.HttpResponse` object that
  34. contains the generated response. Each view function is responsible for
  35. returning an :class:`~django.http.HttpResponse` object. (There are
  36. exceptions, but we'll get to those later.)
  37. .. admonition:: Django's Time Zone
  38. Django includes a :setting:`TIME_ZONE` setting that defaults to
  39. ``America/Chicago``. This probably isn't where you live, so you might want
  40. to change it in your settings file.
  41. Mapping URLs to views
  42. =====================
  43. So, to recap, this view function returns an HTML page that includes the current
  44. date and time. To display this view at a particular URL, you'll need to create a
  45. *URLconf*; see :doc:`/topics/http/urls` for instructions.
  46. Returning errors
  47. ================
  48. Returning HTTP error codes in Django is easy. There are subclasses of
  49. :class:`~django.http.HttpResponse` for a number of common HTTP status codes
  50. other than 200 (which means *"OK"*). You can find the full list of available
  51. subclasses in the :ref:`request/response <ref-httpresponse-subclasses>`
  52. documentation. Just return an instance of one of those subclasses instead of
  53. a normal :class:`~django.http.HttpResponse` in order to signify an error. For
  54. example::
  55. def my_view(request):
  56. # ...
  57. if foo:
  58. return HttpResponseNotFound('<h1>Page not found</h1>')
  59. else:
  60. return HttpResponse('<h1>Page was found</h1>')
  61. There isn't a specialized subclass for every possible HTTP response code,
  62. since many of them aren't going to be that common. However, as documented in
  63. the :class:`~django.http.HttpResponse` documentation, you can also pass the
  64. HTTP status code into the constructor for :class:`~django.http.HttpResponse`
  65. to create a return class for any status code you like. For example::
  66. def my_view(request):
  67. # ...
  68. # Return a "created" (201) response code.
  69. return HttpResponse(status=201)
  70. Because 404 errors are by far the most common HTTP error, there's an easier way
  71. to handle those errors.
  72. The Http404 exception
  73. ---------------------
  74. .. class:: django.http.Http404()
  75. When you return an error such as :class:`~django.http.HttpResponseNotFound`,
  76. you're responsible for defining the HTML of the resulting error page::
  77. return HttpResponseNotFound('<h1>Page not found</h1>')
  78. For convenience, and because it's a good idea to have a consistent 404 error page
  79. across your site, Django provides an ``Http404`` exception. If you raise
  80. ``Http404`` at any point in a view function, Django will catch it and return the
  81. standard error page for your application, along with an HTTP error code 404.
  82. Example usage::
  83. from django.http import Http404
  84. def detail(request, poll_id):
  85. try:
  86. p = Poll.objects.get(pk=poll_id)
  87. except Poll.DoesNotExist:
  88. raise Http404
  89. return render_to_response('polls/detail.html', {'poll': p})
  90. In order to use the ``Http404`` exception to its fullest, you should create a
  91. template that is displayed when a 404 error is raised. This template should be
  92. called ``404.html`` and located in the top level of your template tree.
  93. Customizing error views
  94. =======================
  95. The 404 (page not found) view
  96. -----------------------------
  97. When you raise an ``Http404`` exception, Django loads a special view devoted
  98. to handling 404 errors. By default, it's the view
  99. ``django.views.defaults.page_not_found``, which loads and renders the template
  100. ``404.html``.
  101. This means you need to define a ``404.html`` template in your root template
  102. directory. This template will be used for all 404 errors.
  103. This ``page_not_found`` view should suffice for 99% of Web applications, but if
  104. you want to override the 404 view, you can specify ``handler404`` in your
  105. URLconf, like so::
  106. handler404 = 'mysite.views.my_custom_404_view'
  107. Behind the scenes, Django determines the 404 view by looking for ``handler404``.
  108. By default, URLconfs contain the following line::
  109. from django.conf.urls.defaults import *
  110. That takes care of setting ``handler404`` in the current module. As you can see
  111. in ``django/conf/urls/``, ``handler404`` is set to
  112. ``'django.views.defaults.page_not_found'`` by default.
  113. Three things to note about 404 views:
  114. * The 404 view is also called if Django doesn't find a match after checking
  115. every regular expression in the URLconf.
  116. * If you don't define your own 404 view -- and simply use the
  117. default, which is recommended -- you still have one obligation:
  118. you must create a ``404.html`` template in the root of your
  119. template directory. The default 404 view will use that template
  120. for all 404 errors. The default 404 view will pass one variable
  121. to the template: ``request_path``, which is the URL that resulted
  122. in the 404.
  123. * The 404 view is passed a :class:`~django.template.RequestContext` and
  124. will have access to variables supplied by your
  125. :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g.,
  126. :setting:`MEDIA_URL`).
  127. * If :setting:`DEBUG` is set to ``True`` (in your settings module), then
  128. your 404 view will never be used, and the traceback will be displayed
  129. instead.
  130. The 500 (server error) view
  131. ----------------------------
  132. Similarly, Django executes special-case behavior in the case of runtime errors
  133. in view code. If a view results in an exception, Django will, by default, call
  134. the view ``django.views.defaults.server_error``, which loads and renders the
  135. template ``500.html``.
  136. This means you need to define a ``500.html`` template in your root template
  137. directory. This template will be used for all server errors. The default 500
  138. view passes no variables to this template and is rendered with an empty
  139. ``Context`` to lessen the chance of additional errors.
  140. This ``server_error`` view should suffice for 99% of Web applications, but if
  141. you want to override the view, you can specify ``handler500`` in your
  142. URLconf, like so::
  143. handler500 = 'mysite.views.my_custom_error_view'
  144. Behind the scenes, Django determines the error view by looking for ``handler500``.
  145. By default, URLconfs contain the following line::
  146. from django.conf.urls.defaults import *
  147. That takes care of setting ``handler500`` in the current module. As you can see
  148. in ``django/conf/urls/``, ``handler500`` is set to
  149. ``'django.views.defaults.server_error'`` by default.