Used consistent capitalization and hyphenation of "class-based views" in docs.
This commit is contained in:
parent
39b55537ec
commit
20787b5c29
|
@ -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,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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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,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
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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__)
|
||||
|
||||
|
|
Loading…
Reference in New Issue