Class-based views API reference. For introductory material, see the\nClass-based views topic guide.
\nViewTemplateViewRedirectViewDetailViewListViewFormViewCreateViewUpdateViewDeleteViewViewTemplateViewRedirectViewDetailViewListViewFormViewCreateViewUpdateViewDeleteViewEach request served by a class-based view has an independent state; therefore,\nit is safe to store state variables on the instance (i.e., self.foo = 3 is\na thread-safe operation).
A class-based view is deployed into a URL pattern using the\nas_view() classmethod:
urlpatterns = [\n path('view/', MyView.as_view(size=42)),\n]\nArguments passed into as_view() will\nbe assigned onto the instance that is used to service a request. Using the\nprevious example, this means that every request on MyView is able to use\nself.size. Arguments must correspond to attributes that already exist on\nthe class (return True on a hasattr check).
Base class-based views can be thought of as parent views, which can be\nused by themselves or inherited from. They may not provide all the\ncapabilities required for projects, in which case there are Mixins which\nextend what base views can do.
\nDjango’s generic views are built off of those base views, and were developed\nas a shortcut for common usage patterns such as displaying the details of an\nobject. They take certain common idioms and patterns found in view\ndevelopment and abstract them so that you can quickly write common views of\ndata without having to repeat yourself.
\nMost generic views require the queryset key, which is a QuerySet\ninstance; see Making queries for more information about QuerySet\nobjects.