<commit_before>.. _topics-generic-views:

=============
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.

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
you can quickly write common views of data without having to write too much
code.

We can recognize certain common tasks, like displaying a list of objects, and
write code that displays a list of *any* object. Then the model in question can
be passed as an extra argument to the URLconf.

Django ships with generic views to do the following:

    * Perform common "simple" tasks: redirect to a different page and
      render a given template.

    * Display list and detail pages for a single object. If we were creating an
      application to manage conferences then a ``talk_list`` view and a
      ``registered_user_list`` view would be examples of list views. A single
      talk page is an example of what we call a "detail" view.

    * Present date-based objects in year/month/day archive pages,
      associated detail, and "latest" pages. The Django Weblog's
      (http://www.djangoproject.com/weblog/) year, month, and
      day archives are built with these, as would be a typical
      newspaper's archives.

    * Allow users to create, update, and delete objects -- with or
      without authorization.

Taken together, these views provide easy interfaces to perform the most common
tasks developers encounter.

Using generic views
===================

All of these views are used by creating configuration dictionaries in
your URLconf files and passing those dictionaries as the third member of the
URLconf tuple for a given pattern.

For example, here's a simple URLconf you could use to present a static "about"
page::

    from django.conf.urls.defaults import *
    from django.views.generic.simple import direct_to_template

    urlpatterns = patterns('',
        ('^about/$', direct_to_template, {
            'template': 'about.html'
        })
    )

Though this might seem a bit "magical" at first glance  -- look, a view with no
code! --, actually the ``direct_to_template`` view simply grabs information from
the extra-parameters dictionary and uses that information when rendering the
view.

Because this generic view -- and all the others -- is a regular view functions
like any other, we can reuse it inside our own views. As an example, let's
extend our "about" example to map URLs of the form ``/about/<whatever>/`` to
statically rendered ``about/<whatever>.html``. We'll do this by first modifying
the URLconf to point to a view function:

.. parsed-literal::

    from django.conf.urls.defaults import *
    from django.views.generic.simple import direct_to_template
    **from mysite.books.views import about_pages**

    urlpatterns = patterns('',
        ('^about/$', direct_to_template, {
            'template': 'about.html'
        }),
        **('^about/(\w+)/$', about_pages),**
    )

Next, we'll write the ``about_pages`` view::
<commit_msg>Fixed #11873 -- Corrected typo in generic views docs. Thanks to <NAME> for the report.<commit_after>.. _topics-generic-views:

=============
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.

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
you can quickly write common views of data without having to write too much
code.

We can recognize certain common tasks, like displaying a list of objects, and
write code that displays a list of *any* object. Then the model in question can
be passed as an extra argument to the URLconf.

Django ships with generic views to do the following:

    * Perform common "simple" tasks: redirect to a different page and
      render a given template.

    * Display list and detail pages for a single object. If we were creating an
      application to manage conferences then a ``talk_list`` view and a
      ``registered_user_list`` view would be examples of list views. A single
      talk page is an example of what we call a "detail" view.

    * Present date-based objects in year/month/day archive pages,
      associated detail, and "latest" pages. The Django Weblog's
      (http://www.djangoproject.com/weblog/) year, month, and
      day archives are built with these, as would be a typical
      newspaper's archives.

    * Allow users to create, update, and delete objects -- with or
      without authorization.

Taken together, these views provide easy interfaces to perform the most common
tasks developers encounter.

Using generic views
===================

All of these views are used by creating configuration dictionaries in
your URLconf files and passing those dictionaries as the third member of the
URLconf tuple for a given pattern.

For example, here's a simple URLconf you could use to present a static "about"
page::

    from django.conf.urls.defaults import *
    from django.views.generic.simple import direct_to_template

    urlpatterns = patterns('',
        ('^about/$', direct_to_template, {
            'template': 'about.html'
        })
    )

Though this might seem a bit "magical" at first glance  -- look, a view with no
code! --, actually the ``direct_to_template`` view simply grabs information from
the extra-parameters dictionary and uses that information when rendering the
view.

Because this generic view -- and all the others -- is a regular view function
like any other, we can reuse it inside our own views. As an example, let's
extend our "about" example to map URLs of the form ``/about/<whatever>/`` to
statically rendered ``about/<whatever>.html``. We'll do this by first modifying
the URLconf to point to a view function:

.. parsed-literal::

    from django.conf.urls.defaults import *
    from django.views.generic.simple import direct_to_template
    **from mysite.books.views import about_pages**

    urlpatterns = patterns('',
        ('^about/$', direct_to_template, {
            'template': 'about.html'
        }),
        **('^about/(\w+)/$', about_pages),**
    )

Next, we'll write the ``about_pages`` view::

{'fraction_non_alphanumeric': 0.08262839879154078, 'fraction_numerical': 0.0007552870090634441, 'mean_word_length': 3.575673807878369, 'pattern_counts': {'":': 0, '<': 8, '<?xml version=': 0, '>': 8, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '749953', 'n_tokens_mistral': 1727, 'n_tokens_neox': 1647, 'n_words': 869}