We now have a relatively complete and sophisticated product catalog with products, categories, and additional product information. This acts as the core of our e-commerce application. Now we will write some quick views and get our catalog running and published to a web server.

In the Django design philosophy, views represent a specific interpretation of the data stored in our models. It is through views that templates, and ultimately the outside world, access our model data. Very often the model data we expose in our views are simply the model objects themselves. In other words, we provided direct access to a model object and all of its fields to the template.

Other times, we may be exposing smaller or larger portions of our model data, including QuerySets or lists of models or a subset of all model data that match a specific filter or other ORM expression.

Exposing a full model object or set of objects according to some filter parameter, is so common that Django provides automatic built-in assistance. This is accomplished using 'generic views', of which Django includes over a dozen. They are broken into four basic kinds: simple, date-based, list-based, and create/update/delete (CRUD).

Simple generic views include two functions: direct_to_template and redirect_to. These are by far the simplest possible views and writing by hand more than once would be overkill. The direct_to_template generic view simply renders a regular Django HTML template, with an optional set of variables added to the context. The redirect_to generic view is even simpler; it raises a standard HTTP 302 status code, otherwise known as a "non-permanent redirection". It can also optionally raise a permanent redirection (HTTP 301).

The real power behind generic views becomes evident in the next set: the date-based views. These are designed to create automatic archives for all of your site content organized by date. This is ideal for newspaper or blog applications, where content is published frequently and finding content based on a date is an effective way to interact with the information.

There are seven different date-based views. The majority of these are for specific time intervals: by year, by month, by week, by day, and for the current day. The remaining two views are for content indexes, called archive_index, which can often be used for homepages and for details on a specific object, useful for permalink pages.

The next set of views is called list-based because they process and present lists of model data. There are only two kinds of list-based views: object_list and object_detail. The former provides a template with context variable that represents a list of objects. Usually the template will iterate over this list using a for-loop tag. The latter view, object_detail, provides a simple view of a single item in the list—for example, a single product out of a list of all products in the catalog.

And lastly we have CRUD views. CRUD stands for create, update, and delete, and is used to provide automatic interfaces for users to modify model data in templates. Sometimes users will need to edit information, but are not staff members and cannot use the Django admin tool. This often happens, when users are editing content they have created (user-generated content) or more simply when they need to edit their profile information, such as payment method or shipping address.

CRUD views are extremely useful for simplifying a very common pattern of gathering and editing data. When combined with Django's forms module, its power can be extended even further. We will utilize generic CRUD views in later chapters.

For now, let's build an initial set of views on our product catalog using the list-based generic views. We have two use-cases. The first use-case is where we enlist a set of products in our catalog or within a category in our catalog. The second use-case is a detail page for every product we are selling. Generic views make writing these pages easy. For our catalog homepage we will implement a special-case of the list-based object_list view.

When using generic views, it is rarely necessary to create a views.py file or write any view handling code at all. The bulk of the time, generic views are integrated directly into the URL pattern definitions in our urls.py file. Here is the basic set of URLs for our product catalog:

urlpatterns = patterns(
    'django.views.generic.list_detail',
    url(r'^product/$', 'object_list',
        {'queryset': Product.objects.all()}),
    url(r'^product/(?P<slug>[-w]+)/$', 'object_detail',
        {'queryset': Product.objects.all()}))