Browse Source

Used consistent capitalization and hyphenation of "class-based views" in docs.

Anton Strogonoff 9 years ago
parent
commit
20787b5c29

+ 2 - 2
docs/internals/team.txt

@@ -363,9 +363,9 @@ Donald Stufft
 
 Marc Tamlyn
     Marc started life on the web using Django 1.2 back in 2010, and has never
-    looked back. He was involved with rewriting the class based view
+    looked back. He was involved with rewriting the class-based view
     documentation at DjangoCon EU 2012, and also helped to develop `CCBV`_, an
-    additional class based view reference tool.
+    additional class-based view reference tool.
 
     Marc is currently a full-time parent, part-time developer, and lives in
     Oxford, UK.

+ 1 - 1
docs/ref/class-based-views/index.txt

@@ -1,5 +1,5 @@
 ==============================
-Built-in Class-based views API
+Built-in class-based views API
 ==============================
 
 Class-based views API reference. For introductory material, see the

+ 1 - 1
docs/ref/contrib/messages.txt

@@ -346,7 +346,7 @@ example::
    use one of the ``add_message`` family of methods. It does not hide failures
    that may occur for other reasons.
 
-Adding messages in Class Based Views
+Adding messages in class-based views
 ------------------------------------
 
 .. class:: views.SuccessMessageMixin

+ 1 - 1
docs/ref/utils.txt

@@ -156,7 +156,7 @@ The functions defined in this module share the following properties:
     Converts a function decorator into a method decorator. It can be used to
     decorate methods or classes; in the latter case, ``name`` is the name
     of the method to be decorated and is required. See :ref:`decorating
-    class based views<decorating-class-based-views>` for example usage.
+    class-based views<decorating-class-based-views>` for example usage.
 
     .. versionchanged:: 1.9
 

+ 1 - 1
docs/releases/1.9.txt

@@ -335,7 +335,7 @@ Forms
 Generic Views
 ^^^^^^^^^^^^^
 
-* Class based views generated using ``as_view()`` now have ``view_class``
+* Class-based views generated using ``as_view()`` now have ``view_class``
   and ``view_initkwargs`` attributes.
 
 * :func:`~django.utils.decorators.method_decorator` can now be used to

+ 1 - 1
docs/topics/class-based-views/generic-display.txt

@@ -1,7 +1,7 @@
 .. _Generic views:
 
 ==================================
-Built-in Class-based generic views
+Built-in class-based generic views
 ==================================
 
 Writing Web applications can be monotonous, because we repeat certain patterns

+ 1 - 1
docs/topics/class-based-views/index.txt

@@ -84,7 +84,7 @@ views::
 
 
 For more information on how to use the built in generic views, consult the next
-topic on :doc:`generic class based views</topics/class-based-views/generic-display>`.
+topic on :doc:`generic class-based views</topics/class-based-views/generic-display>`.
 
 .. _supporting-other-http-methods:
 

+ 2 - 2
docs/topics/class-based-views/intro.txt

@@ -1,5 +1,5 @@
 =================================
-Introduction to Class-based views
+Introduction to class-based views
 =================================
 
 Class-based views provide an alternative way to implement views as Python
@@ -43,7 +43,7 @@ The toolkit of base classes and mixins that Django uses to build class-based
 generic views are built for maximum flexibility, and as such have many hooks in
 the form of default method implementations and attributes that you are unlikely
 to be concerned with in the simplest use cases. For example, instead of
-limiting you to a class based attribute for ``form_class``, the implementation
+limiting you to a class-based attribute for ``form_class``, the implementation
 uses a ``get_form`` method, which calls a ``get_form_class`` method, which in
 its default implementation just returns the ``form_class`` attribute of the
 class. This gives you several options for specifying what form to use, from a

+ 2 - 3
docs/topics/class-based-views/mixins.txt

@@ -204,11 +204,10 @@ the box.
     understandable to someone else coming to it later, and with fewer
     interactions to worry about you will save yourself some thinking. (Of
     course, you can always dip into Django's implementation of the generic
-    class based views for inspiration on how to tackle problems.)
+    class-based views for inspiration on how to tackle problems.)
 
 .. _method resolution order: https://www.python.org/download/releases/2.3/mro/
 
-
 Using SingleObjectMixin with View
 ---------------------------------
 
@@ -593,7 +592,7 @@ views as separate as possible.
 More than just HTML
 ===================
 
-Where class based views shine is when you want to do the same thing many times.
+Where class-based views shine is when you want to do the same thing many times.
 Suppose you're writing an API, and every view should return JSON instead of
 rendered HTML.
 

+ 1 - 1
docs/topics/http/urls.txt

@@ -52,7 +52,7 @@ algorithm the system follows to determine which Python code to execute:
    one that matches the requested URL.
 
 4. Once one of the regexes matches, Django imports and calls the given view,
-   which is a simple Python function (or a :doc:`class based view
+   which is a simple Python function (or a :doc:`class-based view
    </topics/class-based-views/index>`). The view gets passed the following
    arguments:
 

+ 1 - 1
docs/topics/testing/tools.txt

@@ -506,7 +506,7 @@ Specifically, a ``Response`` object has the following attributes:
             # my_view here is a function based view
             self.assertEqual(response.resolver_match.func, my_view)
 
-            # class based views need to be compared by name, as the functions
+            # class-based views need to be compared by name, as the functions
             # generated by as_view() won't be equal
             self.assertEqual(response.resolver_match.func.__name__, MyView.as_view().__name__)