Documentação de API de views baseada em classes. Para uma introdução, veja Class-based views topic guide.
\nViewTemplateViewRedirectViewDetailViewListViewFormViewCreateViewUpdateViewDeleteViewCada requisição processada por uma class-based view possui um estado independente; por essa razão, é seguro guardar estado de variavéis na instância usada (i.e, self.foo = 3 é uma operação thread-safe )
Uma class-based view é implantada sob um padrão de URL usando o as_view() classmethod:
urlpatterns = [\n path('view/', MyView.as_view(size=42)),\n]\nArgumentos passados para as_view() serão atribuidos a instância usada no processamento da requisição. Usando o exemplo anterior, significa que toda requisição on MyView é capaz de acessar self.size. Os argumentos devem corresponder aos atributos que já existem na classe (retornar True na checagem do metodo hasattr )
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 Fazendo consultas for more information about QuerySet\nobjects.