0
0
mirror of https://github.com/django/django.git synced 2024-11-29 22:56:46 +01:00
django/docs/ref/class-based-views/index.txt
Tim Graham d73d0e071c Fixed #22218 -- Deprecated django.conf.urls.patterns.
Thanks Carl Meyer for the suggestion and Alex Gaynor and Carl for reviews.
2014-04-03 07:28:10 -04:00

63 lines
2.2 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

=================
Class-based views
=================
Class-based views API reference. For introductory material, see
:doc:`/topics/class-based-views/index`.
.. toctree::
:maxdepth: 3
base
generic-display
generic-editing
generic-date-based
mixins
flattened-index
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:`~django.views.generic.base.View.as_view()` classmethod::
urlpatterns = [
url(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 shouldn't use a list, dictionary, or any other
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.
Arguments passed into :meth:`~django.views.generic.base.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``. Arguments must correspond to attributes that already exist on
the class (return ``True`` on a ``hasattr`` check).
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.
Djangos 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.