Small grammar, consistency, and import fixes for the new class-based-views topic guide.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14263 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Gabriel Hurley
parent
26e8e53cf4
commit
b05b8cf091
|
|
@ -9,7 +9,7 @@ Class-based generic views
|
|||
function-based implementation has been deprecated in favor of the
|
||||
class-based approach described here.
|
||||
|
||||
For the reference to the old on details on the old implementation,
|
||||
For details on the previous generic views implementation,
|
||||
see the :doc:`topic guide </topics/generic-views>` and
|
||||
:doc:`detailed reference </topics/generic-views>`.
|
||||
|
||||
|
|
@ -38,9 +38,9 @@ Django ships with generic views to do the following:
|
|||
talk page is an example of what we call a "detail" view.
|
||||
|
||||
* Present date-based objects in year/month/day archive pages,
|
||||
associated detail, and "latest" pages. The Django Weblog's
|
||||
(http://www.djangoproject.com/weblog/) year, month, and
|
||||
day archives are built with these, as would be a typical
|
||||
associated detail, and "latest" pages.
|
||||
`The Django Weblog <http://www.djangoproject.com/weblog/>`_'s
|
||||
year, month, and day archives are built with these, as would be a typical
|
||||
newspaper's archives.
|
||||
|
||||
* Allow users to create, update, and delete objects -- with or
|
||||
|
|
@ -53,17 +53,16 @@ tasks developers encounter.
|
|||
Simple usage
|
||||
============
|
||||
|
||||
Class-based generic views (and indeed any class-based views that are
|
||||
based on the base classes Django provides) can be configured in two
|
||||
Class-based generic views (and any class-based views that inherit from
|
||||
the base classes Django provides) can be configured in two
|
||||
ways: subclassing, or passing in arguments directly in the URLconf.
|
||||
|
||||
When you subclass a class-based view, you can override attributes
|
||||
(such as the template name, ``template_name``) or methods (such as
|
||||
``get_context_data``) in your subclass to provide new values or
|
||||
methods. Consider, for example, a view that just displays one
|
||||
template, ``about.html``. Django has a generic view to do this -
|
||||
:class:`~django.views.generic.base.TemplateView` - so we can just
|
||||
subclass it, and override the template name::
|
||||
(such as the ``template_name``) or methods (such as ``get_context_data``)
|
||||
in your subclass to provide new values or methods. Consider, for example,
|
||||
a view that just displays one template, ``about.html``. Django has a
|
||||
generic view to do this - :class:`~django.views.generic.base.TemplateView` -
|
||||
so we can just subclass it, and override the template name::
|
||||
|
||||
# some_app/views.py
|
||||
from django.views.generic import TemplateView
|
||||
|
|
@ -104,7 +103,7 @@ Generic views of objects
|
|||
|
||||
:class:`~django.views.generic.base.TemplateView` certainly is useful,
|
||||
but Django's generic views really shine when it comes to presenting
|
||||
views on your database content. Because it's such a common task,
|
||||
views of your database content. Because it's such a common task,
|
||||
Django comes with a handful of built-in generic views that make
|
||||
generating list and detail views of objects incredibly easy.
|
||||
|
||||
|
|
@ -175,7 +174,7 @@ might look like the following::
|
|||
That's really all there is to it. All the cool features of generic views come
|
||||
from changing the "info" dictionary passed to the generic view. The
|
||||
:doc:`generic views reference</ref/class-based-views>` documents all the generic
|
||||
views and all their options in detail; the rest of this document will consider
|
||||
views and their options in detail; the rest of this document will consider
|
||||
some of the common ways you might customize and extend generic views.
|
||||
|
||||
|
||||
|
|
@ -201,10 +200,10 @@ Making "friendly" template contexts
|
|||
-----------------------------------
|
||||
|
||||
You might have noticed that our sample publisher list template stores all the
|
||||
books in a variable named ``object_list``. While this works just fine, it isn't
|
||||
all that "friendly" to template authors: they have to "just know" that they're
|
||||
dealing with publishers here. A better name for that variable would be
|
||||
``publisher_list``; that variable's content is pretty obvious.
|
||||
publishers in a variable named ``object_list``. While this works just fine, it
|
||||
isn't all that "friendly" to template authors: they have to "just know" that
|
||||
they're dealing with publishers here. A more obvious name for that variable
|
||||
would be ``publisher_list``.
|
||||
|
||||
We can change the name of that variable easily with the ``context_object_name``
|
||||
attribute - here, we'll override it in the URLconf, since it's a simple change:
|
||||
|
|
@ -237,11 +236,11 @@ However, there is; you can subclass
|
|||
implementation of the ``get_context_data`` method. The default
|
||||
implementation of this that comes with
|
||||
:class:`~django.views.generic.detail.DetailView` simply adds in the
|
||||
object being displayed to the template, but we can override it to show
|
||||
object being displayed to the template, but you can override it to show
|
||||
more::
|
||||
|
||||
from django.views.generic import DetailView
|
||||
from some_app.models import Publisher, Book
|
||||
from books.models import Publisher, Book
|
||||
|
||||
class PublisherDetailView(DetailView):
|
||||
|
||||
|
|
@ -268,7 +267,7 @@ specify the objects that the view will operate upon -- you can also
|
|||
specify the list of objects using the ``queryset`` argument::
|
||||
|
||||
from django.views.generic import DetailView
|
||||
from some_app.models import Publisher, Book
|
||||
from books.models import Publisher, Book
|
||||
|
||||
class PublisherDetailView(DetailView):
|
||||
|
||||
|
|
@ -279,8 +278,9 @@ Specifying ``model = Publisher`` is really just shorthand for saying
|
|||
``queryset = Publisher.objects.all()``. However, by using ``queryset``
|
||||
to define a filtered list of objects you can be more specific about the
|
||||
objects that will be visible in the view (see :doc:`/topics/db/queries`
|
||||
for more information about ``QuerySet`` objects, and see the
|
||||
:doc:`generic views reference</ref/generic-views>` for the complete details).
|
||||
for more information about :class:`QuerySet` objects, and see the
|
||||
:doc:`class-based views reference </ref/class-based-views>` for the complete
|
||||
details).
|
||||
|
||||
To pick a simple example, we might want to order a list of books by
|
||||
publication date, with the most recent first::
|
||||
|
|
@ -304,7 +304,7 @@ technique (here, illustrated using subclassing rather than by passing arguments
|
|||
in the URLconf)::
|
||||
|
||||
from django.views.generic import ListView
|
||||
from some_app.models import Book
|
||||
from books.models import Book
|
||||
|
||||
class AcmeBookListView(ListView):
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ We'll deal with this problem in the next section.
|
|||
If you get a 404 when requesting ``/books/acme/``, check to ensure you
|
||||
actually have a Publisher with the name 'ACME Publishing'. Generic
|
||||
views have an ``allow_empty`` parameter for this case. See the
|
||||
:doc:`generic views reference</ref/class-based-views>` for more details.
|
||||
:doc:`class-based-views reference</ref/class-based-views>` for more details.
|
||||
|
||||
|
||||
Dynamic filtering
|
||||
|
|
@ -337,9 +337,10 @@ key in the URL. Earlier we hard-coded the publisher's name in the URLconf, but
|
|||
what if we wanted to write a view that displayed all the books by some arbitrary
|
||||
publisher?
|
||||
|
||||
Handily, the ListView has a ``get_queryset`` method we can override. Previously,
|
||||
it has just been returning the value of the ``queryset`` attribute, but now we
|
||||
can add more logic.
|
||||
Handily, the ListView has a
|
||||
:meth:`~django.views.generic.detail.ListView.get_queryset` method we can
|
||||
override. Previously, it has just been returning the value of the ``queryset``
|
||||
attribute, but now we can add more logic.
|
||||
|
||||
The key part to making this work is that when class-based views are called,
|
||||
various useful things are stored on ``self``; as well as the request
|
||||
|
|
@ -348,7 +349,7 @@ various useful things are stored on ``self``; as well as the request
|
|||
|
||||
Here, we have a URLconf with a single captured group::
|
||||
|
||||
from some_app.views import PublisherBookListView
|
||||
from books.views import PublisherBookListView
|
||||
|
||||
urlpatterns = patterns('',
|
||||
(r'^books/(\w+)/$', PublisherBookListView.as_view()),
|
||||
|
|
@ -358,7 +359,7 @@ Next, we'll write the ``PublisherBookListView`` view itself::
|
|||
|
||||
from django.shortcuts import get_object_or_404
|
||||
from django.views.generic import ListView
|
||||
from some_app.models import Book, Publisher
|
||||
from books.models import Book, Publisher
|
||||
|
||||
class PublisherBookListView(ListView):
|
||||
|
||||
|
|
@ -420,7 +421,7 @@ custom view:
|
|||
|
||||
.. parsed-literal::
|
||||
|
||||
from some_app.views import AuthorDetailView
|
||||
from books.views import AuthorDetailView
|
||||
|
||||
urlpatterns = patterns('',
|
||||
#...
|
||||
|
|
@ -431,7 +432,7 @@ Then we'd write our new view - ``get_object`` is the method that retrieves the
|
|||
object, so we simply override it and wrap the call::
|
||||
|
||||
import datetime
|
||||
from some_app.models import Author
|
||||
from books.models import Author
|
||||
from django.views.generic import DetailView
|
||||
from django.shortcuts import get_object_or_404
|
||||
|
||||
|
|
@ -472,12 +473,15 @@ Each generic view is composed out of a series of mixins, and each
|
|||
mixin contributes a little piece of the entire view. Some of these
|
||||
mixins -- such as
|
||||
:class:`~django.views.generic.base.TemplateResponseMixin` -- are
|
||||
specifically designed for rendering content to a HTML response using a
|
||||
specifically designed for rendering content to an HTML response using a
|
||||
template. However, you can write your own mixins that perform
|
||||
different rendering behavior.
|
||||
|
||||
For example, a simple JSON mixin might look something like this::
|
||||
|
||||
from django import http
|
||||
from django.utils import simplejson as json
|
||||
|
||||
class JSONResponseMixin(object):
|
||||
def render_to_response(self, context):
|
||||
"Returns a JSON response containing 'context' as payload"
|
||||
|
|
|
|||
Loading…
Reference in New Issue