Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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
  • Loading branch information...
commit b05b8cf091dc622041550ea608cad4fc4a1ed028 1 parent 26e8e53
authored October 18, 2010

Showing 1 changed file with 37 additions and 33 deletions. Show diff stats Hide diff stats

  1. 70  docs/topics/class-based-views.txt
70  docs/topics/class-based-views.txt
@@ -9,7 +9,7 @@ Class-based generic views
9 9
     function-based implementation has been deprecated in favor of the
10 10
     class-based approach described here.
11 11
 
12  
-    For the reference to the old on details on the old implementation,
  12
+    For details on the previous generic views implementation,
13 13
     see the :doc:`topic guide </topics/generic-views>` and
14 14
     :doc:`detailed reference </topics/generic-views>`.
15 15
 
@@ -38,9 +38,9 @@ Django ships with generic views to do the following:
38 38
       talk page is an example of what we call a "detail" view.
39 39
 
40 40
     * Present date-based objects in year/month/day archive pages,
41  
-      associated detail, and "latest" pages. The Django Weblog's
42  
-      (http://www.djangoproject.com/weblog/) year, month, and
43  
-      day archives are built with these, as would be a typical
  41
+      associated detail, and "latest" pages.
  42
+      `The Django Weblog <http://www.djangoproject.com/weblog/>`_'s
  43
+      year, month, and day archives are built with these, as would be a typical
44 44
       newspaper's archives.
45 45
 
46 46
     * Allow users to create, update, and delete objects -- with or
@@ -53,17 +53,16 @@ tasks developers encounter.
53 53
 Simple usage
54 54
 ============
55 55
 
56  
-Class-based generic views (and indeed any class-based views that are
57  
-based on the base classes Django provides) can be configured in two
  56
+Class-based generic views (and any class-based views that inherit from
  57
+the base classes Django provides) can be configured in two
58 58
 ways: subclassing, or passing in arguments directly in the URLconf.
59 59
 
60 60
 When you subclass a class-based view, you can override attributes
61  
-(such as the template name, ``template_name``) or methods (such as
62  
-``get_context_data``) in your subclass to provide new values or
63  
-methods. Consider, for example, a view that just displays one
64  
-template, ``about.html``. Django has a generic view to do this -
65  
-:class:`~django.views.generic.base.TemplateView` - so we can just
66  
-subclass it, and override the template name::
  61
+(such as the ``template_name``) or methods (such as ``get_context_data``)
  62
+in your subclass to provide new values or methods. Consider, for example,
  63
+a view that just displays one template, ``about.html``. Django has a
  64
+generic view to do this - :class:`~django.views.generic.base.TemplateView` -
  65
+so we can just subclass it, and override the template name::
67 66
 
68 67
     # some_app/views.py
69 68
     from django.views.generic import TemplateView
@@ -104,7 +103,7 @@ Generic views of objects
104 103
 
105 104
 :class:`~django.views.generic.base.TemplateView` certainly is useful,
106 105
 but Django's generic views really shine when it comes to presenting
107  
-views on your database content. Because it's such a common task,
  106
+views of your database content. Because it's such a common task,
108 107
 Django comes with a handful of built-in generic views that make
109 108
 generating list and detail views of objects incredibly easy.
110 109
 
@@ -175,7 +174,7 @@ might look like the following::
175 174
 That's really all there is to it. All the cool features of generic views come
176 175
 from changing the "info" dictionary passed to the generic view. The
177 176
 :doc:`generic views reference</ref/class-based-views>` documents all the generic
178  
-views and all their options in detail; the rest of this document will consider
  177
+views and their options in detail; the rest of this document will consider
179 178
 some of the common ways you might customize and extend generic views.
180 179
 
181 180
 
@@ -201,10 +200,10 @@ Making "friendly" template contexts
201 200
 -----------------------------------
202 201
 
203 202
 You might have noticed that our sample publisher list template stores all the
204  
-books in a variable named ``object_list``. While this works just fine, it isn't
205  
-all that "friendly" to template authors: they have to "just know" that they're
206  
-dealing with publishers here. A better name for that variable would be
207  
-``publisher_list``; that variable's content is pretty obvious.
  203
+publishers in a variable named ``object_list``. While this works just fine, it
  204
+isn't all that "friendly" to template authors: they have to "just know" that
  205
+they're dealing with publishers here. A more obvious name for that variable
  206
+would be ``publisher_list``.
208 207
 
209 208
 We can change the name of that variable easily with the ``context_object_name``
210 209
 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
237 236
 implementation of the ``get_context_data`` method. The default
238 237
 implementation of this that comes with
239 238
 :class:`~django.views.generic.detail.DetailView` simply adds in the
240  
-object being displayed to the template, but we can override it to show
  239
+object being displayed to the template, but you can override it to show
241 240
 more::
242 241
 
243 242
     from django.views.generic import DetailView
244  
-    from some_app.models import Publisher, Book
  243
+    from books.models import Publisher, Book
245 244
 
246 245
     class PublisherDetailView(DetailView):
247 246
 
@@ -268,7 +267,7 @@ specify the objects that the view will operate upon -- you can also
268 267
 specify the list of objects using the ``queryset`` argument::
269 268
 
270 269
     from django.views.generic import DetailView
271  
-    from some_app.models import Publisher, Book
  270
+    from books.models import Publisher, Book
272 271
 
273 272
     class PublisherDetailView(DetailView):
274 273
 
@@ -279,8 +278,9 @@ Specifying ``model = Publisher`` is really just shorthand for saying
279 278
 ``queryset = Publisher.objects.all()``. However, by using ``queryset``
280 279
 to define a filtered list of objects you can be more specific about the
281 280
 objects that will be visible in the view (see :doc:`/topics/db/queries`
282  
-for more information about ``QuerySet`` objects, and see the
283  
-:doc:`generic views reference</ref/generic-views>` for the complete details).
  281
+for more information about :class:`QuerySet` objects, and see the
  282
+:doc:`class-based views reference </ref/class-based-views>` for the complete
  283
+details).
284 284
 
285 285
 To pick a simple example, we might want to order a list of books by
286 286
 publication date, with the most recent first::
@@ -304,7 +304,7 @@ technique (here, illustrated using subclassing rather than by passing arguments
304 304
 in the URLconf)::
305 305
 
306 306
     from django.views.generic import ListView
307  
-    from some_app.models import Book
  307
+    from books.models import Book
308 308
 
309 309
     class AcmeBookListView(ListView):
310 310
 
@@ -326,7 +326,7 @@ We'll deal with this problem in the next section.
326 326
     If you get a 404 when requesting ``/books/acme/``, check to ensure you
327 327
     actually have a Publisher with the name 'ACME Publishing'.  Generic
328 328
     views have an ``allow_empty`` parameter for this case.  See the
329  
-    :doc:`generic views reference</ref/class-based-views>` for more details.
  329
+    :doc:`class-based-views reference</ref/class-based-views>` for more details.
330 330
 
331 331
 
332 332
 Dynamic filtering
@@ -337,9 +337,10 @@ key in the URL. Earlier we hard-coded the publisher's name in the URLconf, but
337 337
 what if we wanted to write a view that displayed all the books by some arbitrary
338 338
 publisher?
339 339
 
340  
-Handily, the ListView has a ``get_queryset`` method we can override. Previously,
341  
-it has just been returning the value of the ``queryset`` attribute, but now we
342  
-can add more logic.
  340
+Handily, the ListView has a
  341
+:meth:`~django.views.generic.detail.ListView.get_queryset` method we can
  342
+override. Previously, it has just been returning the value of the ``queryset``
  343
+attribute, but now we can add more logic.
343 344
 
344 345
 The key part to making this work is that when class-based views are called,
345 346
 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
348 349
 
349 350
 Here, we have a URLconf with a single captured group::
350 351
 
351  
-    from some_app.views import PublisherBookListView
  352
+    from books.views import PublisherBookListView
352 353
 
353 354
     urlpatterns = patterns('',
354 355
         (r'^books/(\w+)/$', PublisherBookListView.as_view()),
@@ -358,7 +359,7 @@ Next, we'll write the ``PublisherBookListView`` view itself::
358 359
 
359 360
     from django.shortcuts import get_object_or_404
360 361
     from django.views.generic import ListView
361  
-    from some_app.models import Book, Publisher
  362
+    from books.models import Book, Publisher
362 363
 
363 364
     class PublisherBookListView(ListView):
364 365
 
@@ -420,7 +421,7 @@ custom view:
420 421
 
421 422
 .. parsed-literal::
422 423
 
423  
-    from some_app.views import AuthorDetailView
  424
+    from books.views import AuthorDetailView
424 425
 
425 426
     urlpatterns = patterns('',
426 427
         #...
@@ -431,7 +432,7 @@ Then we'd write our new view - ``get_object`` is the method that retrieves the
431 432
 object, so we simply override it and wrap the call::
432 433
 
433 434
     import datetime
434  
-    from some_app.models import Author
  435
+    from books.models import Author
435 436
     from django.views.generic import DetailView
436 437
     from django.shortcuts import get_object_or_404
437 438
 
@@ -472,12 +473,15 @@ Each generic view is composed out of a series of mixins, and each
472 473
 mixin contributes a little piece of the entire view. Some of these
473 474
 mixins -- such as
474 475
 :class:`~django.views.generic.base.TemplateResponseMixin` -- are
475  
-specifically designed for rendering content to a HTML response using a
  476
+specifically designed for rendering content to an HTML response using a
476 477
 template. However, you can write your own mixins that perform
477 478
 different rendering behavior.
478 479
 
479 480
 For example, a simple JSON mixin might look something like this::
480 481
 
  482
+    from django import http
  483
+    from django.utils import simplejson as json
  484
+
481 485
     class JSONResponseMixin(object):
482 486
         def render_to_response(self, context):
483 487
             "Returns a JSON response containing 'context' as payload"

0 notes on commit b05b8cf

Please sign in to comment.
Something went wrong with that request. Please try again.