# documentação Django 3.1.9.dev

# API nativa de views baseadas em classes

Documentação de API de views baseada em classes. Para uma introdução, veja Class-based views topic guide.

- “Views” de base
  - `View`
  - `TemplateView`
  - `RedirectView`
- Views de exibição genéricas
  - `DetailView`
  - `ListView`
- Views de edição genérica
  - `FormView`
  - `CreateView`
  - `UpdateView`
  - `DeleteView`
- “Views” de datas genéricas
  - `ArchiveIndexView`
  - `YearArchiveView`
  - `MonthArchiveView`
  - `WeekArchiveView`
  - `DayArchiveView`
  - `TodayArchiveView`
  - `DateDetailView`
- Class-based views mixins
  - Simple mixins
    - `ContextMixin`
    - `TemplateResponseMixin`
  - Single object mixins
    - `SingleObjectMixin`
    - `SingleObjectTemplateResponseMixin`
  - Multiple object mixins
    - `MultipleObjectMixin`
    - `MultipleObjectTemplateResponseMixin`
  - Editing mixins
    - `FormMixin`
    - `ModelFormMixin`
    - `ProcessFormView`
    - `DeletionMixin`
  - Date-based mixins
    - `YearMixin`
    - `MonthMixin`
    - `DayMixin`
    - `WeekMixin`
    - `DateMixin`
    - `BaseDateListView`
- “Views” genéricas baseadas em classes - índice linear
  - “Views” genéricas simples.
    - `View`
    - `TemplateView`
    - `RedirectView`
  - “Views” de detalhes
    - `DetailView`
  - “Views” de listagem
    - `ListView`
  - “Views” de edição
    - `FormView`
    - `CreateView`
    - `UpdateView`
    - `DeleteView`
  - “Views” de dados baseados em datas
    - `ArchiveIndexView`
    - `YearArchiveView`
    - `MonthArchiveView`
    - `WeekArchiveView`
    - `DayArchiveView`
    - `TodayArchiveView`
    - `DateDetailView`

## Especificação

Cada 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 = [
        path('view/', MyView.as_view(size=42)),
    ]

Thread safety with view arguments

Argumentos passados a uma view são compartilhados por cada instância de uma view. Isto significa que você não deve utilizar uma lista, um dicionário ou qualquer outro objeto mutável como um argumento para uma view. Caso você o faça e o objeto compartilhado seja modificado, as ações de um usuário acessando sua view poderá ter efeito para usuários subsequentes que estejam acessando a mesma view.

Argumentos 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` )

## Visualização Básica vs Genérica

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 Fazendo consultas for more information about `QuerySet` objects.