diff options
Diffstat (limited to 'docs/topics/class-based-views')
| -rw-r--r-- | docs/topics/class-based-views/generic-display.txt | 16 | ||||
| -rw-r--r-- | docs/topics/class-based-views/generic-editing.txt | 8 | ||||
| -rw-r--r-- | docs/topics/class-based-views/index.txt | 7 | ||||
| -rw-r--r-- | docs/topics/class-based-views/intro.txt | 3 | ||||
| -rw-r--r-- | docs/topics/class-based-views/mixins.txt | 49 |
5 files changed, 42 insertions, 41 deletions
diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt index e72fe5cfe6..aa39716611 100644 --- a/docs/topics/class-based-views/generic-display.txt +++ b/docs/topics/class-based-views/generic-display.txt @@ -4,8 +4,8 @@ Built-in class-based generic views Writing web applications can be monotonous, because we repeat certain patterns again and again. Django tries to take away some of that monotony at the model -and template layers, but web developers also experience this boredom at the view -level. +and template layers, but web developers also experience this boredom at the +view level. Django's *generic views* were developed to ease that pain. They take certain common idioms and patterns found in view development and abstract them so that @@ -229,8 +229,8 @@ you can override it to send more:: Generally, ``get_context_data`` will merge the context data of all parent classes with those of the current class. To preserve this behavior in your own classes where you want to alter the context, you should be sure to call - ``get_context_data`` on the super class. When no two classes try to define the - same key, this will give the expected results. However if any class + ``get_context_data`` on the super class. When no two classes try to define + the same key, this will give the expected results. However if any class attempts to override a key after parent classes have set it (after the call to super), any children of that class will also need to explicitly set it after super if they want to be sure to override all parents. If you're @@ -295,8 +295,8 @@ list of books by a particular publisher, you can use the same technique:: template_name = "books/acme_list.html" Notice that along with a filtered ``queryset``, we're also using a custom -template name. If we didn't, the generic view would use the same template as the -"vanilla" object list, which might not be what we want. +template name. If we didn't, the generic view would use the same template as +the "vanilla" object list, which might not be what we want. Also notice that this isn't a very elegant way of doing publisher-specific books. If we want to add another publisher page, we'd need another handful of @@ -317,8 +317,8 @@ Dynamic filtering Another common need is to filter down the objects given in a list page by some key in the URL. Earlier we hardcoded 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? +what if we wanted to write a view that displayed all the books by some +arbitrary publisher? Handily, the ``ListView`` has a :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` method we diff --git a/docs/topics/class-based-views/generic-editing.txt b/docs/topics/class-based-views/generic-editing.txt index 45c36409ce..2e200b35ff 100644 --- a/docs/topics/class-based-views/generic-editing.txt +++ b/docs/topics/class-based-views/generic-editing.txt @@ -84,7 +84,8 @@ special requirements; see below for examples. You don't even need to provide a ``success_url`` for :class:`~django.views.generic.edit.CreateView` or :class:`~django.views.generic.edit.UpdateView` - they will use -:meth:`~django.db.models.Model.get_absolute_url` on the model object if available. +:meth:`~django.db.models.Model.get_absolute_url` on the model object if +available. If you want to use a custom :class:`~django.forms.ModelForm` (for instance to add extra validation), set @@ -146,8 +147,9 @@ inner ``Meta`` class on :class:`~django.forms.ModelForm`. Unless you define the form class in another way, the attribute is required and the view will raise an :exc:`~django.core.exceptions.ImproperlyConfigured` exception if it's not. -If you specify both the :attr:`~django.views.generic.edit.ModelFormMixin.fields` -and :attr:`~django.views.generic.edit.FormMixin.form_class` attributes, an +If you specify both the +:attr:`~django.views.generic.edit.ModelFormMixin.fields` and +:attr:`~django.views.generic.edit.FormMixin.form_class` attributes, an :exc:`~django.core.exceptions.ImproperlyConfigured` exception will be raised. Finally, we hook these new views into the URLconf: diff --git a/docs/topics/class-based-views/index.txt b/docs/topics/class-based-views/index.txt index f69f70cf5a..6af39bca9a 100644 --- a/docs/topics/class-based-views/index.txt +++ b/docs/topics/class-based-views/index.txt @@ -23,8 +23,8 @@ Basic examples ============== Django provides base view classes which will suit a wide range of applications. -All views inherit from the :class:`~django.views.generic.base.View` class, which -handles linking the view into the URLs, HTTP method dispatching and other +All views inherit from the :class:`~django.views.generic.base.View` class, +which handles linking the view into the URLs, HTTP method dispatching and other common features. :class:`~django.views.generic.base.RedirectView` provides a HTTP redirect, and :class:`~django.views.generic.base.TemplateView` extends the base class to make it also render a template. @@ -84,7 +84,8 @@ method instead, which provides a function-like entry to class-based 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: diff --git a/docs/topics/class-based-views/intro.txt b/docs/topics/class-based-views/intro.txt index ab84c8c9ac..429ca38a65 100644 --- a/docs/topics/class-based-views/intro.txt +++ b/docs/topics/class-based-views/intro.txt @@ -17,7 +17,8 @@ The relationship and history of generic views, class-based views, and class-base In the beginning there was only the view function contract, Django passed your function an :class:`~django.http.HttpRequest` and expected back an -:class:`~django.http.HttpResponse`. This was the extent of what Django provided. +:class:`~django.http.HttpResponse`. This was the extent of what Django +provided. Early on it was recognized that there were common idioms and patterns found in view development. Function-based generic views were introduced to abstract diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt index bb1a6349dc..6b2c435e1b 100644 --- a/docs/topics/class-based-views/mixins.txt +++ b/docs/topics/class-based-views/mixins.txt @@ -112,11 +112,10 @@ context data for template renders. To then make a :class:`~django.template.response.TemplateResponse`, :class:`DetailView` uses -:class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`, -which extends :class:`~django.views.generic.base.TemplateResponseMixin`, -overriding -:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names` -as discussed above. It actually provides a fairly sophisticated set of options, +:class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`, which +extends :class:`~django.views.generic.base.TemplateResponseMixin`, overriding +:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names` as +discussed above. It actually provides a fairly sophisticated set of options, but the main one that most people are going to use is ``<app_label>/<model_name>_detail.html``. The ``_detail`` part can be changed by setting @@ -135,20 +134,18 @@ paginated) list of objects, typically a using that list of objects. To get the objects, :class:`~django.views.generic.list.ListView` uses -:class:`~django.views.generic.list.MultipleObjectMixin`, which -provides both -:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` -and -:meth:`~django.views.generic.list.MultipleObjectMixin.paginate_queryset`. Unlike -with :class:`~django.views.generic.detail.SingleObjectMixin`, there's no need -to key off parts of the URL to figure out the queryset to work with, so the -default uses the +:class:`~django.views.generic.list.MultipleObjectMixin`, which provides both +:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` and +:meth:`~django.views.generic.list.MultipleObjectMixin.paginate_queryset`. +Unlike with :class:`~django.views.generic.detail.SingleObjectMixin`, there's no +need to key off parts of the URL to figure out the queryset to work with, so +the default uses the :attr:`~django.views.generic.list.MultipleObjectMixin.queryset` or -:attr:`~django.views.generic.list.MultipleObjectMixin.model` attribute -on the view class. A common reason to override -:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` -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. +:attr:`~django.views.generic.list.MultipleObjectMixin.model` attribute on the +view class. A common reason to override +:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` 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 @@ -159,13 +156,12 @@ it. To make a :class:`~django.template.response.TemplateResponse`, :class:`ListView` then uses -:class:`~django.views.generic.list.MultipleObjectTemplateResponseMixin`; -as with :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin` +:class:`~django.views.generic.list.MultipleObjectTemplateResponseMixin`; as +with :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin` above, this overrides ``get_template_names()`` to provide :meth:`a range of -options <django.views.generic.list.MultipleObjectTemplateResponseMixin>`, -with the most commonly-used being -``<app_label>/<model_name>_list.html``, with the ``_list`` part again -being taken from the +options <django.views.generic.list.MultipleObjectTemplateResponseMixin>`, with +the most commonly-used being ``<app_label>/<model_name>_list.html``, with the +``_list`` part again being taken from the :attr:`~django.views.generic.list.MultipleObjectTemplateResponseMixin.template_name_suffix` attribute. (The date based generic views use suffixes such as ``_archive``, ``_archive_year`` and so on to use different templates for the various @@ -635,8 +631,9 @@ For example, a 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 -as :func:`~django.views.generic.base.TemplateResponseMixin.render_to_response`. +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 need to mix it into a ``TemplateView`` for example, and override ``render_to_response()`` to call ``render_to_json_response()`` instead:: |