2012-06-11 08:34:00 +00:00
|
|
|
|
=================
|
|
|
|
|
|
Class-based views
|
|
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
|
|
|
Class-based views API reference. For introductory material, see
|
|
|
|
|
|
:doc:`/topics/class-based-views/index`.
|
|
|
|
|
|
|
|
|
|
|
|
.. toctree::
|
|
|
|
|
|
:maxdepth: 1
|
|
|
|
|
|
|
|
|
|
|
|
base
|
|
|
|
|
|
generic-display
|
|
|
|
|
|
generic-editing
|
|
|
|
|
|
generic-date-based
|
|
|
|
|
|
mixins
|
|
|
|
|
|
|
|
|
|
|
|
Specification
|
|
|
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
|
|
Each request served by a class-based view has an independent state; therefore,
|
|
|
|
|
|
it is safe to store state variables on the instance (i.e., ``self.foo = 3`` is
|
|
|
|
|
|
a thread-safe operation).
|
|
|
|
|
|
|
|
|
|
|
|
A class-based view is deployed into a URL pattern using the
|
|
|
|
|
|
:meth:`~View.as_view()` classmethod::
|
|
|
|
|
|
|
|
|
|
|
|
urlpatterns = patterns('',
|
|
|
|
|
|
(r'^view/$', MyView.as_view(size=42)),
|
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
|
|
.. admonition:: Thread safety with view arguments
|
|
|
|
|
|
|
|
|
|
|
|
Arguments passed to a view are shared between every instance of a view.
|
|
|
|
|
|
This means that you shoudn't use a list, dictionary, or any other
|
2012-08-09 20:22:22 +00:00
|
|
|
|
mutable object as an argument to a view. If you do and the shared object
|
|
|
|
|
|
is modified, the actions of one user visiting your view could have an
|
|
|
|
|
|
effect on subsequent users visiting the same view.
|
2012-06-11 08:34:00 +00:00
|
|
|
|
|
|
|
|
|
|
Any argument passed into :meth:`~View.as_view()` will be assigned onto the
|
|
|
|
|
|
instance that is used to service a request. Using the previous example,
|
|
|
|
|
|
this means that every request on ``MyView`` is able to use ``self.size``.
|
|
|
|
|
|
|
|
|
|
|
|
Base vs Generic views
|
|
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
|
|
|
|
Base class-based views can be thought of as *parent* views, which can be
|
|
|
|
|
|
used by themselves or inherited from. They may not provide all the
|
|
|
|
|
|
capabilities required for projects, in which case there are Mixins which
|
|
|
|
|
|
extend what base views can do.
|
|
|
|
|
|
|
|
|
|
|
|
Django’s generic views are built off of those base views, and were developed
|
|
|
|
|
|
as a shortcut for common usage patterns such as displaying the details of an
|
|
|
|
|
|
object. 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 repeat yourself.
|
|
|
|
|
|
|
|
|
|
|
|
Most generic views require the ``queryset`` key, which is a ``QuerySet``
|
|
|
|
|
|
instance; see :doc:`/topics/db/queries` for more information about ``QuerySet``
|
|
|
|
|
|
objects.
|
