Les vues fondées sur les classes sont une autre manière d’implémenter les vues par des objets Python au lieu de fonctions. Elles ne remplacent pas les vues fondées sur les fonction, mais présentent certaines différences et avantages comparées aux vues fondées sur les fonctions :
\nL’organisation du code en lien avec les méthodes HTTP spécifiques (GET, POST, etc.) peut se faire par des méthodes séparées au lieu d’utiliser un branchement conditionnel.
Des techniques orientées objet comme les « mixins » (héritage multiple) peuvent être utilisées pour factoriser le code en composants réutilisables.
Au départ, il n’y avait que le contrat de la vue fonction à laquelle Django transmet un requête HttpRequest et de laquelle il s’attend à recevoir une réponse HttpResponse. C’était ce que Django lui-même pratiquait.
Assez rapidement, on a reconnu des idiomes et des modèles courants dans le développement des vues. Les vues génériques fondées sur les fonctions ont été introduites pour abstraire ces pratiques et faciliter le développement de vues pour ces cas courants.
\nLe problème avec les vues génériques fondées sur les fonctions, c’est qu’elles recouvrent bien les cas simples, mais qu’il n’est pas possible de les étendre ou de les personnaliser au-delà de simples options de configurations, limitant ainsi leur utilité dans bien des applications du monde réel.
\nLes vues génériques fondées sur les classes ont été crées avec les mêmes objectifs que celles fondées sur les fonctions, pour faciliter le développement de vues. Cependant, la manière d’implémenter cette solution par l’utilisation de mixins fournit un ensemble d’outils aboutissant à des vues génériques fondées sur les classes bien plus souples et extensibles que leur contrepartie fondées sur les fonctions.
\nSi vous avez essayé d’utiliser les vues génériques fondées sur les fonctions par le passé et que vous les avez trouvées trop limitées, vous ne devriez pas simplement considérer les vues génériques fondées sur les classes comme des équivalents, mais plutôt comme une nouvelle approche pour résoudre les problèmes d’origine que les vues génériques étaient censées résoudre.
\nL’ensemble des classes de base et des mixins que Django utilise pour construire les vues génériques fondées sur les classes sont conçues pour une souplesse maximale, et présentent ainsi de nombreux points d’accrochage sous les forme d’implémentation de méthodes par défaut et d’attributs qui ne vous concerneront probablement pas dans les cas d’utilisation les plus simples. Par exemple, au lieu de se limiter à un attribut de classe pour form_class, l’implémentation utilise une méthode get_form appelant à son tour la méthode get_form_class qui dans son implémentation par défaut ne fait que renvoyer l’attribut form_class de la classe. Cela vous donne plusieurs options pour indiquer le formulaire à utiliser, que ce soit par un simple attribut ou par l’appel dynamique à une méthode que l’on peut surcharger. Ces options paraissent ajouter une complexité un peu absurde dans des situations simples, mais sans elles, les scénarios plus compliqués seraient limités.
À la base, une vue fondée sur les classes permet de répondre à différentes méthodes de requête HTTP par différentes méthodes d’une classe plutôt que de faire appel à des branchements conditionnels dans une unique vue de type fonction.
\nAlors que le code pour gérer la méthode HTTP GET dans une fonction de vue ressemble à quelque chose comme cela :
from django.http import HttpResponse\n\ndef my_view(request):\n if request.method == 'GET':\n # <view logic>\n return HttpResponse('result')\nDans une vue fondée sur les classes, cela devient :
\nfrom django.http import HttpResponse\nfrom django.views import View\n\nclass MyView(View):\n def get(self, request):\n # <view logic>\n return HttpResponse('result')\nComme le résolveur d’URL de Django est conçu pour envoyer la requête et ses paramètres associés à une fonction exécutable et non pas à une classe, les vues fondées sur les classes possèdent une méthode de classe as_view() qui renvoie une fonction pouvant être appelée lorsqu’une requête arrive avec une URL correspondant au motif associé. La fonction crée une instance de la classe et appelle sa méthode dispatch(). dispatch examine la requête pour déterminer s’il s’agit d’un GET, d’un POST, etc. et relaie la requête à une méthode correspondante si elle existe, ou génère l’erreur HttpResponseNotAllowed dans le cas contraire :
# urls.py\nfrom django.urls import path\nfrom myapp.views import MyView\n\nurlpatterns = [\n path('about/', MyView.as_view()),\n]\nIl vaut la peine de relever que ce qui est renvoyé par la méthode est identique à ce qui est renvoyé par une vue de type fonction, en l’occurrence une instance de HttpResponse. Cela signifie que les raccourcis http ou les objets TemplateResponse peuvent tout à fait être utilisés dans une vue fondée sur les classes.
Même si une vue fondée sur les classes minimale ne nécessite aucun attribut de classe pour faire son travail, les attributs de classe sont utiles dans beaucoup d’architectures basées sur les classes et il existe deux façons de configurer ou de définir des attributs de classe.
\nLa première est la manière standard de Python d’hériter ou de surcharger des attributs et des méthodes dans les sous-classes. Ainsi si la classe parente avait un attribut greeting comme ceci :
from django.http import HttpResponse\nfrom django.views import View\n\nclass GreetingView(View):\n greeting = "Good Day"\n\n def get(self, request):\n return HttpResponse(self.greeting)\nVous pouvez surcharger cela dans une sous-classe :
\nclass MorningGreetingView(GreetingView):\n greeting = "Morning to ya"\nUne autre option est de configurer des attributs de classe comme paramètres nommés dans l’appel à as_view() dans la configuration d’URL :
urlpatterns = [\n path('about/', GreetingView.as_view(greeting="G'day")),\n]\nLes mixins sont une forme d’héritage multiple où les comportements et les attributs de plusieurs classes parentes peuvent être combinés.
\nPar exemple, dans les vues génériques fondées sur les classes, il existe un mixin nommé TemplateResponseMixin dont le rôle principal est de définir la méthode render_to_response(). Lorsqu’il est combiné avec le comportement de la classe de base View, le résultat est une classe TemplateView qui distribue les requêtes vers les méthodes correspondantes (un comportement défini dans la classe de base View), et qui possède une méthode render_to_response() utilisant un attribut template_name pour renvoyer un objet TemplateResponse (comportement défini dans TemplateResponseMixin).
Les mixins sont une très bonne façon de réutiliser du code entre plusieurs classes, mais il y a aussi un revers de médaille. Plus votre code est réparti entre des mixins, plus il sera difficile de lire une classe enfant et de comprendre exactement ce qu’elle fait, et plus il sera difficile de savoir quelle méthode de quel mixin surcharger si vous héritez d’une structure avec une profonde arborescence d’héritage.
\nNotez également que vous ne pouvez hériter que d’une vue générique, c’est-à-dire qu’une seule classe parente peut hériter de View et toutes les autres classes (le cas échéant) doivent être des mixins. Si vous essayez d’hériter de plus d’une classe héritant de View, par exemple pour utiliser un formulaire au sommet d’une liste et combiner ProcessFormView avec ListView, cela ne marchera pas comme espéré.
Une vue de type fonction qui gère des formulaires peut ressembler à ceci :
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\n\nfrom .forms import MyForm\n\ndef myview(request):\n if request.method == "POST":\n form = MyForm(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect('/success/')\n else:\n form = MyForm(initial={'key': 'value'})\n\n return render(request, 'form_template.html', {'form': form})\nUne vue équivalente fondée sur les classes pourrait ressembler à ceci :
\nfrom django.http import HttpResponseRedirect\nfrom django.shortcuts import render\nfrom django.views import View\n\nfrom .forms import MyForm\n\nclass MyFormView(View):\n form_class = MyForm\n initial = {'key': 'value'}\n template_name = 'form_template.html'\n\n def get(self, request, *args, **kwargs):\n form = self.form_class(initial=self.initial)\n return render(request, self.template_name, {'form': form})\n\n def post(self, request, *args, **kwargs):\n form = self.form_class(request.POST)\n if form.is_valid():\n # <process form cleaned data>\n return HttpResponseRedirect('/success/')\n\n return render(request, self.template_name, {'form': form})\nIl s’agit d’un cas très simple, mais vous pouvez voir que vous aurez ensuite l’option de personnaliser cette vue en surchargeant l’un des ses attributs de classe, par ex. form_class, à travers la configuration d’URL ou par l’héritage et la surcharge de l’une ou plusieurs de ses méthodes (les deux pouvant être combinés).
L’extension des vues fondées sur les classes n’est pas limitée aux mixins. Il est aussi possible d’utiliser des décorateurs. Comme les vues fondées sur les classes ne sont pas des fonctions, leur décoration fonctionne différemment selon que vous utilisez as_view() ou que vous créez une sous-classe.
La façon la plus simple de décorer les vues fondées sur les classes est de décorer le résultat de la méthode as_view(). L’endroit le plus commode pour le faire est la configuration d’URL dans laquelle la vue est déployée :
from django.contrib.auth.decorators import login_required, permission_required\nfrom django.views.generic import TemplateView\n\nfrom .views import VoteView\n\nurlpatterns = [\n path('about/', login_required(TemplateView.as_view(template_name="secret.html"))),\n path('vote/', permission_required('polls.can_vote')(VoteView.as_view())),\n]\nCette approche applique le décorateur au niveau de l’instance. Si vous souhaitez que chaque instance d’une vue soit systématiquement décorée, vous devez suivre une autre approche.
\nPour décorer toutes les instances d’une vue fondée sur les classes, vous devez décorer la définition de classe elle-même. À cet effet, appliquez le décorateur à la méthode dispatch() de la classe.
Une méthode de classe n’est pas totalement identique à une fonction autonome, il n’est donc pas possible de simplement appliquer un décorateur de fonction à la méthode, il faut préalablement le transformer en un décorateur de méthode. Le décorateur method_decorator transforme un décorateur de fonction en un décorateur de méthode afin qu’il puisse être utilisé sur une méthode d’instance. Par exemple :
from django.contrib.auth.decorators import login_required\nfrom django.utils.decorators import method_decorator\nfrom django.views.generic import TemplateView\n\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\n\n @method_decorator(login_required)\n def dispatch(self, *args, **kwargs):\n return super().dispatch(*args, **kwargs)\nOu plus succintement, vous pouvez plutôt décorer la classe et passer le nom de la méthode à décorer dans le paramètre nommé name:
@method_decorator(login_required, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\nSi un ensemble de décorateurs sont utilisés à plusieurs endroits, vous pouvez définir une liste ou un tuple de décorateurs et l’utiliser au lieu d’appeler plusieurs fois method_decorator(). Ces deux classes sont équivalentes :
decorators = [never_cache, login_required]\n\n@method_decorator(decorators, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\n\n@method_decorator(never_cache, name='dispatch')\n@method_decorator(login_required, name='dispatch')\nclass ProtectedView(TemplateView):\n template_name = 'secret.html'\nLes décorateurs traitent une requête dans l’ordre où ils sont placés comme décorateurs. Dans l’exemple, never_cache() traitera la requête avant login_required().
Dans cet exemple, chaque instance de ProtectedView possédera la protection de login.