Skip to content

Commit

Permalink
[1.2.X] Fixed #14744 - Add cross-links to docs/topics/http/views.txt.…
Browse files Browse the repository at this point in the history
… Thanks adamv for the patch.

Backport of r14720 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@14721 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information
timgraham committed Nov 26, 2010
1 parent 165a860 commit db345ac
Showing 1 changed file with 17 additions and 15 deletions.
32 changes: 17 additions & 15 deletions docs/topics/http/views.txt
Expand Up @@ -29,22 +29,22 @@ Here's a view that returns the current date and time, as an HTML document:


Let's step through this code one line at a time: Let's step through this code one line at a time:


* First, we import the class ``HttpResponse``, which lives in the * First, we import the class :class:`~django.http.HttpResponse` from the
``django.http`` module, along with Python's ``datetime`` library. :mod:`django.http` module, along with Python's ``datetime`` library.


* Next, we define a function called ``current_datetime``. This is the view * Next, we define a function called ``current_datetime``. This is the view
function. Each view function takes an ``HttpRequest`` object as its first function. Each view function takes an :class:`~django.http.HttpRequest`
parameter, which is typically named ``request``. object 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 Note that the name of the view function doesn't matter; it doesn't have to
be named in a certain way in order for Django to recognize it. We're be named in a certain way in order for Django to recognize it. We're
calling it ``current_datetime`` here, because that name clearly indicates calling it ``current_datetime`` here, because that name clearly indicates
what it does. what it does.


* The view returns an ``HttpResponse`` object that contains the * The view returns an :class:`~django.http.HttpResponse` object that
generated response. Each view function is responsible for returning an contains the generated response. Each view function is responsible for
``HttpResponse`` object. (There are exceptions, but we'll get to those returning an :class:`~django.http.HttpResponse` object. (There are
later.) exceptions, but we'll get to those later.)


.. admonition:: Django's Time Zone .. admonition:: Django's Time Zone


Expand Down Expand Up @@ -97,8 +97,8 @@ The Http404 exception


.. class:: django.http.Http404() .. class:: django.http.Http404()


When you return an error such as ``HttpResponseNotFound``, you're responsible When you return an error such as :class:`~django.http.HttpResponseNotFound`,
for defining the HTML of the resulting error page:: you're responsible for defining the HTML of the resulting error page::


return HttpResponseNotFound('<h1>Page not found</h1>') return HttpResponseNotFound('<h1>Page not found</h1>')


Expand Down Expand Up @@ -164,12 +164,14 @@ Three things to note about 404 views:
to the template: ``request_path``, which is the URL that resulted to the template: ``request_path``, which is the URL that resulted
in the 404. in the 404.


* The 404 view is passed a ``RequestContext`` and will have access to * The 404 view is passed a :class:`~django.template.RequestContext` and
variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g., will have access to variables supplied by your
``MEDIA_URL``). :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g.,
:setting:`MEDIA_URL`).


* If ``DEBUG`` is set to ``True`` (in your settings module), then your 404 * If :setting:`DEBUG` is set to ``True`` (in your settings module), then
view will never be used, and the traceback will be displayed instead. your 404 view will never be used, and the traceback will be displayed
instead.


The 500 (server error) view The 500 (server error) view
---------------------------- ----------------------------
Expand Down

0 comments on commit db345ac

Please sign in to comment.