mirror of https://github.com/django/django.git
60 lines
2.0 KiB
Plaintext
60 lines
2.0 KiB
Plaintext
|
=================
|
|||
|
|
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
|
|||
|
|
variable object as an argument to a view. If you did, the actions of
|
|||
|
|
one user visiting your view could have an effect on subsequent users
|
|||
|
|
visiting the same view.
|
|||
|
|
|
|||
|
|
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.
|