Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Fixed #20658 -- Fixed bad reST formatting and missing parentheses in …

…the docs for CBV mixins

Thanks to Keryn Knight for the report.
  • Loading branch information...
commit c6862d57c1e987f0f98a77826d19358b9040bad1 1 parent ec371ac
Loïc Bistuer loic authored bmispelon committed
Showing with 14 additions and 13 deletions.
  1. +14 −13 docs/topics/class-based-views/mixins.txt
27 docs/topics/class-based-views/mixins.txt
View
@@ -34,7 +34,7 @@ interface to working with templates in class-based views.
:class:`~django.views.generic.base.TemplateResponseMixin`
Every built in view which returns a
:class:`~django.template.response.TemplateResponse` will call the
- :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
+ :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
method that ``TemplateResponseMixin`` provides. Most of the time this
will be called for you (for instance, it is called by the ``get()`` method
implemented by both :class:`~django.views.generic.base.TemplateView` and
@@ -44,7 +44,7 @@ interface to working with templates in class-based views.
it. For an example of this, see the :ref:`JSONResponseMixin example
<jsonresponsemixin-example>`.
- ``render_to_response`` itself calls
+ ``render_to_response()`` itself calls
:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names`,
which by default will just look up
:attr:`~django.views.generic.base.TemplateResponseMixin.template_name` on
@@ -60,9 +60,9 @@ interface to working with templates in class-based views.
:class:`~django.views.generic.base.ContextMixin`
Every built in view which needs context data, such as for rendering a
template (including ``TemplateResponseMixin`` above), should call
- :meth:`~django.views.generic.base.ContextMixin.get_context_data` passing
+ :meth:`~django.views.generic.base.ContextMixin.get_context_data()` passing
any data they want to ensure is in there as keyword arguments.
- ``get_context_data`` returns a dictionary; in ``ContextMixin`` it
+ ``get_context_data()`` returns a dictionary; in ``ContextMixin`` it
simply returns its keyword arguments, but it is common to override this to
add more members to the dictionary.
@@ -107,7 +107,7 @@ URLConf, and looks the object up either from the
on the view, or the
:attr:`~django.views.generic.detail.SingleObjectMixin.queryset`
attribute if that's provided). ``SingleObjectMixin`` also overrides
-:meth:`~django.views.generic.base.ContextMixin.get_context_data`,
+:meth:`~django.views.generic.base.ContextMixin.get_context_data()`,
which is used across all Django's built in class-based views to supply
context data for template renders.
@@ -152,7 +152,7 @@ here would be to dynamically vary the objects, such as depending on
the current user or to exclude posts in the future for a blog.
:class:`~django.views.generic.list.MultipleObjectMixin` also overrides
-:meth:`~django.views.generic.base.ContextMixin.get_context_data` to
+:meth:`~django.views.generic.base.ContextMixin.get_context_data()` to
include appropriate context variables for pagination (providing
dummies if pagination is disabled). It relies on ``object_list`` being
passed in as a keyword argument, which :class:`ListView` arranges for
@@ -286,15 +286,16 @@ One way to do this is to combine :class:`ListView` with
for the paginated list of books can hang off the publisher found as the single
object. In order to do this, we need to have two different querysets:
-**``Publisher`` queryset for use in ``get_object``**
+``Publisher`` queryset for use in
+ :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
We'll set the ``model`` attribute on the view and rely on the default
implementation of ``get_object()`` to fetch the correct ``Publisher``
object.
-**``Book`` queryset for use by ``ListView``**
- The default implementation of ``get_queryset`` uses the ``model`` attribute
+``Book`` queryset for use by :class:`~django.views.generic.list.ListView`
+ The default implementation of ``get_queryset()`` uses the ``model`` attribute
to construct the queryset. This conflicts with our use of this attribute
- for ``get_object`` so we'll override that method and have it return
+ for ``get_object()`` so we'll override that method and have it return
the queryset of ``Book`` objects linked to the ``Publisher`` we're looking
at.
@@ -641,10 +642,10 @@ For example, a simple JSON mixin might look something like this::
information on how to correctly transform Django models and querysets into
JSON.
-This mixin provides a ``render_to_json_response`` method with the same signature
+This mixin provides a ``render_to_json_response()`` method with the same signature
as :func:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`.
To use it, we simply need to mix it into a ``TemplateView`` for example,
-and override ``render_to_response`` to call ``render_to_json_response`` instead::
+and override ``render_to_response()`` to call ``render_to_json_response()`` instead::
from django.views.generic import TemplateView
@@ -693,5 +694,5 @@ that the user requested::
Because of the way that Python resolves method overloading, the call to
``super(HybridDetailView, self).render_to_response(context)`` ends up
calling the
-:meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
+:meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
implementation of :class:`~django.views.generic.base.TemplateResponseMixin`.
Please sign in to comment.
Something went wrong with that request. Please try again.