mirror of
https://github.com/django/django.git
synced 2024-12-25 02:26:12 +00:00
63 lines
2.3 KiB
Plaintext
63 lines
2.3 KiB
Plaintext
==============================
|
|
Built-in class-based views API
|
|
==============================
|
|
|
|
Class-based views API reference. For introductory material, see the
|
|
:doc:`/topics/class-based-views/index` topic guide.
|
|
|
|
.. 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 = [
|
|
path("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.
|
|
|
|
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.
|