mirror of
https://github.com/django/django.git
synced 2024-12-01 15:42:04 +01:00
c4c7fbcc0d
Many thanks to Daniel Greenfeld, James Aylett, Marc Tamlyn, Simon Williams, Danilo Bargen and Luke Plant for their work on this.
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.
|