# Documentation Django 3.1.9.dev

# API des vues intégrées fondées sur les classes

La référence de l’API des vues fondées sur les classes. Pour une introduction à ce concept, consultez le guide thématique Vues fondées sur les classes.

- Vues de base
  - `View`
  - `TemplateView`
  - `RedirectView`
- Vues génériques d’affichage
  - `DetailView`
  - `ListView`
- Vues génériques d’édition
  - `FormView`
  - `CreateView`
  - `UpdateView`
  - `DeleteView`
- Vues génériques basées sur les dates
  - `ArchiveIndexView`
  - `YearArchiveView`
  - `MonthArchiveView`
  - `WeekArchiveView`
  - `DayArchiveView`
  - `TodayArchiveView`
  - `DateDetailView`
- Vues « mixins » fondées sur les classes
  - Mixins simples
    - `ContextMixin`
    - `TemplateResponseMixin`
  - Classes mixins pour objet unique
    - `SingleObjectMixin`
    - `SingleObjectTemplateResponseMixin`
  - Classes mixins pour objets multiples
    - `MultipleObjectMixin`
    - `MultipleObjectTemplateResponseMixin`
  - Classes mixins d’édition
    - `FormMixin`
    - `ModelFormMixin`
    - `ProcessFormView`
    - `DeletionMixin`
  - Mixins basées sur les dates
    - `YearMixin`
    - `MonthMixin`
    - `DayMixin`
    - `WeekMixin`
    - `DateMixin`
    - `BaseDateListView`
- Vues génériques fondées sur les classes - index général
  - Vues génériques simples
    - `View`
    - `TemplateView`
    - `RedirectView`
  - Vues de détail
    - `DetailView`
  - Vues de liste
    - `ListView`
  - Vues d’édition
    - `FormView`
    - `CreateView`
    - `UpdateView`
    - `DeleteView`
  - Vues basées sur les dates
    - `ArchiveIndexView`
    - `YearArchiveView`
    - `MonthArchiveView`
    - `WeekArchiveView`
    - `DayArchiveView`
    - `TodayArchiveView`
    - `DateDetailView`

## Spécification

Chaque requête servie par une vue basée sur une classe possède un état indépendant ; il est donc possible de stocker des variables d’état au sein de l’instance de la vue (par exemple, `self.foo = 3` respecte la concurrence entre fils d’exécution).

Une vue basée sur une classe est déployée dans un motif d’URL en utilisant la méthode de classe `as_view()`:

    urlpatterns = [
        path('view/', MyView.as_view(size=42)),
    ]

Concurrence d’exécution sur les paramètres de vue

Les paramètres transmis à une vue sont partagés entre toutes les instances de la vue. Cela signifie que vous ne devriez pas utiliser une liste, un dictionnaire ou tout autre objet mutant comme paramètre d’une vue. Si vous le faites et que l’objet partagé est modifié, les actions d’un visiteur du site sur une vue pourraient avoir des effets sur d’autres utilisateurs accédant à la même vue.

Les paramètres fournis à la méthode `as_view()` sont attribués à l’instance créée pour servir la requête. Dans l’exemple précédent, cela signifie que chaque requête à `MyView` a la possibilité d’utiliser `self.size`. Les paramètres doivent correspondre à des attributs déjà existants dans la classe (la méthode `hasattr` doit renvoyer `True`).

## Vues de base et vues génériques

Les vues de base fondées sur les classes peuvent être considérées comme des vues parentes qui peuvent être utilisées telles quelles ou comme classe parente. Elles ne contiennent pas toutes les fonctionnalités requises par les projets, c’est pour cela qu’il y a des vues de type `Mixin` qui étendent les fonctionnalités des vues de base.

Les vues génériques de Django sont construites à partir de ces vues de base et ont été développées comme des raccourcis pour répondre aux besoins les plus fréquents, comme pour l’affichage des détails d’un objet. Elles s’attachent à trouver des motifs ou idiomes courants dans le développement des vues et à les abstraire de façon à ce qu’on puisse rapidement écrire des vues courantes sans devoir se répéter inutilement.

La plupart des vues génériques ont besoin de la clé `queryset` qui est une instance de `QuerySet`. Consultez Création de requêtes pour plus d’informations sur les objets `QuerySet`.