diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index 3ff11da..2818f42 100644
a
|
b
|
Here's a view that returns the current date and time, as an HTML document:
|
29 | 29 | |
30 | 30 | Let's step through this code one line at a time: |
31 | 31 | |
32 | | * First, we import the class ``HttpResponse``, which lives in the |
33 | | ``django.http`` module, along with Python's ``datetime`` library. |
| 32 | * First, we import the class :class:`~django.http.HttpResponse` from the |
| 33 | :mod:`django.http` module, along with Python's ``datetime`` library. |
34 | 34 | |
35 | 35 | * Next, we define a function called ``current_datetime``. This is the view |
36 | | function. Each view function takes an ``HttpRequest`` object as its first |
37 | | parameter, which is typically named ``request``. |
| 36 | function. Each view function takes an :class:`~django.http.HttpRequest` |
| 37 | object as its first parameter, which is typically named ``request``. |
38 | 38 | |
39 | 39 | Note that the name of the view function doesn't matter; it doesn't have to |
40 | 40 | be named in a certain way in order for Django to recognize it. We're |
41 | 41 | calling it ``current_datetime`` here, because that name clearly indicates |
42 | 42 | what it does. |
43 | 43 | |
44 | | * The view returns an ``HttpResponse`` object that contains the |
45 | | generated response. Each view function is responsible for returning an |
46 | | ``HttpResponse`` object. (There are exceptions, but we'll get to those |
47 | | later.) |
| 44 | * The view returns an :class:`~django.http.HttpResponse` object that |
| 45 | contains the generated response. Each view function is responsible for |
| 46 | returning an :class:`~django.http.HttpResponse` object. (There are |
| 47 | exceptions, but we'll get to those later.) |
48 | 48 | |
49 | 49 | .. admonition:: Django's Time Zone |
50 | 50 | |
… |
… |
The Http404 exception
|
97 | 97 | |
98 | 98 | .. class:: django.http.Http404() |
99 | 99 | |
100 | | When you return an error such as ``HttpResponseNotFound``, you're responsible |
101 | | for defining the HTML of the resulting error page:: |
| 100 | When you return an error such as :class:`~django.http.HttpResponseNotFound`, |
| 101 | you're responsible for defining the HTML of the resulting error page:: |
102 | 102 | |
103 | 103 | return HttpResponseNotFound('<h1>Page not found</h1>') |
104 | 104 | |
… |
… |
Three things to note about 404 views:
|
164 | 164 | to the template: ``request_path``, which is the URL that resulted |
165 | 165 | in the 404. |
166 | 166 | |
167 | | * The 404 view is passed a ``RequestContext`` and will have access to |
168 | | variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g., |
169 | | ``MEDIA_URL``). |
| 167 | * The 404 view is passed a :class:`~django.template.RequestContext` and |
| 168 | will have access to variables supplied by your |
| 169 | :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g., |
| 170 | :setting:`MEDIA_URL`). |
170 | 171 | |
171 | | * If ``DEBUG`` is set to ``True`` (in your settings module), then your 404 |
172 | | view will never be used, and the traceback will be displayed instead. |
| 172 | * If :setting:`DEBUG` is set to ``True`` (in your settings module), then |
| 173 | your 404 view will never be used, and the traceback will be displayed |
| 174 | instead. |
173 | 175 | |
174 | 176 | The 500 (server error) view |
175 | 177 | ---------------------------- |