Fixed #10336 -- Added improved documentation of generic views. Thanks to Jacob...

      :ref:`Managing files <topics-files>` | 

      :ref:`Custom storage <howto-custom-file-storage>`

    * **Generic views:**

      :ref:`Overview<topics-generic-views>` |

      :ref:`Built-in generic views<ref-generic-views>`

    * **Advanced:**

      :ref:`Generic views <ref-generic-views>` | 

      :ref:`Generating CSV <howto-outputting-csv>` |

      :ref:`Generating PDF <howto-outputting-pdf>`

The work is mostly done, but here's what's left, in rough order of priority.

    * Fix up generic view docs: adapt Chapter 9 of the Django Book (consider

      this TODO item my permission and license) into

      ``topics/generic-views.txt``; remove the intro material from

      ``ref/generic-views.txt`` and just leave the function reference.

    * Change the "Added/changed in development version" callouts to proper

      Sphinx ``.. versionadded::`` or ``.. versionchanged::`` directives.

abstracted into "generic views" that let you quickly provide common views of

an object without actually needing to write any Python code.

Django's generic views contain the following:

A general introduction to generic views can be found in the :ref:`topic guide

<topics-generic-views>`.

    * A set of views for doing list/detail interfaces.

    * A set of views for year/month/day archive pages and associated

      detail and "latest" pages (for example, the Django weblog's year_,

      month_, day_, detail_, and latest_ pages).

    * A set of views for creating, editing, and deleting objects.

.. _year: http://www.djangoproject.com/weblog/2005/

.. _month: http://www.djangoproject.com/weblog/2005/jul/

.. _day: http://www.djangoproject.com/weblog/2005/jul/20/

.. _detail: http://www.djangoproject.com/weblog/2005/jul/20/autoreload/

.. _latest: http://www.djangoproject.com/weblog/

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 the URLconf for the

simple weblog app that drives the blog on djangoproject.com::

    from django.conf.urls.defaults import *

    from django_website.apps.blog.models import Entry

    info_dict = {

        'queryset': Entry.objects.all(),

        'date_field': 'pub_date',

    }

    urlpatterns = patterns('django.views.generic.date_based',

       (r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/(?P<day>\w{1,2})/(?P<slug>[-\w]+)/$', 'object_detail', info_dict),

       (r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/(?P<day>\w{1,2})/$',               'archive_day',   info_dict),

       (r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/$',                                'archive_month', info_dict),

       (r'^(?P<year>\d{4})/$',                                                    'archive_year',  info_dict),

       (r'^$',                                                                    'archive_index', info_dict),

    )

As you can see, this URLconf defines a few options in ``info_dict``.

``'queryset'`` gives the generic view a ``QuerySet`` of objects to use (in this

case, all of the ``Entry`` objects) and tells the generic view which model is

being used.

Documentation of each generic view follows, along with a list of all keyword

arguments that a generic view expects. Remember that as in the example above,

arguments may either come from the URL pattern (as ``month``, ``day``,

``year``, etc. do above) or from the additional-information dictionary (as for

``queryset``, ``date_field``, etc.).

This reference contains details of Django's built-in generic views, along with

a list of all keyword arguments that a generic view expects. Remember that

arguments may either come from the URL pattern or from the ``extra_context``

additional-information dictionary.

Most generic views require the ``queryset`` key, which is a ``QuerySet``

instance; see :ref:`topics-db-queries` for more information about ``QuerySet``

objects.

Most views also take an optional ``extra_context`` dictionary that you can use

to pass any auxiliary information you wish to the view. The values in the

``extra_context`` dictionary can be either functions (or other callables) or

other objects. Functions are evaluated just before they are passed to the

template. However, note that QuerySets retrieve and cache their data when they

are first evaluated, so if you want to pass in a QuerySet via

``extra_context`` that is always fresh you need to wrap it in a function or

lambda that returns the QuerySet.

"Simple" generic views

======================

   forms/index

   forms/modelforms

   templates

   generic-views

   files

   testing

   auth