Les vues fondées sur les classes intégrées dans Django fournissent de nombreuses fonctionnalités, mais certaines d’entre elles pourraient être utiles de manière indépendante. Par exemple, si l’on écrit une vue qui utilise un gabarit pour produire une réponse HTTP, mais sans utiliser TemplateView; ou encore si l’on veut utiliser un gabarit seulement pour une requête POST et faire quelque chose de totalement différent pour les requêtes GET. Même si on pourrait utiliser directement TemplateResponse, on se retrouverait avec pas mal de code dupliqué.
C’est pour cette raison que Django fournit aussi un certain nombre de mixins englobant des fonctionnalités de manière distincte. Le rendu de gabarits, par exemple, est isolé dans la classe TemplateResponseMixin. La documentation de référence de Django contient une documentation complète de toutes les classes mixins.
Deux classes mixins centrales sont à disposition pour aider à présenter une interface cohérente pour travailler avec les gabarits dans les vues fondées sur les classes.
\nTemplateResponseMixinChaque vue intégrée renvoyant une réponse TemplateResponse appelle la méthode render_to_response() fournie par TemplateResponseMixin. Dans la plupart des cas, cet appel se fait automatiquement (par exemple, elle est appelée par la méthode get() aussi bien de TemplateView que de DetailView). De même, il est peu probable que vous ayez besoin de la surcharger, bien que cela peut se révéler utile si vous voulez que la réponse renvoie du contenu non rendu par un gabarit Django. Vous pouvez trouver un exemple d’un tel usage dans l’exemple JSONResponseMixin.
render_to_response() appelle elle-même get_template_names() qui consulte l’attribut template_name de la vue, par défaut. Deux autres mixins (SingleObjectTemplateResponseMixin et MultipleObjectTemplateResponseMixin) surchargent cette méthode pour offrir des valeurs par défaut plus souples lorsqu’il s’agit de manipuler des objets réels.
ContextMixinChaque vue intégrée nécessitant des données de contexte, comme pour effectuer le rendu d’un gabarit (y compris TemplateResponseMixin ci-dessus), doit appeler get_context_data() en transmettant sous forme de paramètres nommés les données qu’elle souhaite y placer. get_context_data() renvoie un dictionnaire ; dans ContextMixin, elle renvoie ses paramètres nommés, mais il est fréquent de surcharger cela pour ajouter davantage de contenu dans ce dictionnaire. Vous pouvez également utiliser l’attribut extra_context.
Voyons comment deux des vues fondées sur les classes de Django sont construites à partir de mixins fournissant des fonctionnalités isolées. Nous examinerons DetailView qui produit une vue de détail d’un objet et ListView qui produit une liste d’objets, généralement à partir d’un jeu de requête, avec pagination facultative. Ceci nous amènera à étudier quatre mixins qui, combinées entre elles, fournissent des fonctionnalités utiles lors du traitement d’un objet Django unique ou d’un ensemble d’objets.
Il existe également des classes mixins dans les vues génériques d’édition (FormView et les vues spécifiques aux modèles CreateView, UpdateView et DeleteView), ainsi que dans les vues génériques centrées sur les dates. Ces classes sont décrites dans la documentation de référence des mixins.
DetailView: traitement d’un seul objet DjangoLien vers cette rubrique#Pour afficher le détail d’un objet, il y a fondamentalement deux choses à faire : récupérer l’objet, puis produire une réponse TemplateResponse à l’aide du gabarit adéquat, en transmettant l’objet dans le contexte.
Pour obtenir l’objet, DetailView se base sur SingleObjectMixin qui fournit une méthode get_object() qui va rechercher l’objet en se basant sur l’URL de la requête (elle cherche les paramètres nommés pk et slug tels que déclarés dans la configuration d’URL et sélectionne l’objet en utilisant soit l’attribut model de la vue, soit l’attribut queryset si celui-ci est présent). SingleObjectMixin surcharge aussi get_context_data(), qui est utilisée dans toutes les vues fondées sur les classes de Django pour fournir les données de contexte servant au rendu des gabarits.
Pour produire la réponse TemplateResponse, DetailView utilise SingleObjectTemplateResponseMixin, qui étend TemplateResponseMixin, surchargeant get_template_names() comme expliqué plus haut. Il fournit en réalité un bon nombre d’options élaborées, mais le nom que la plupart des gens vont utiliser est <étiquette_application>/<nom_modèle>_detail.html. La partie _detail peut être modifiée en définissant un attribut template_name_suffix différent dans une sous-classe (par exemple, les vues génériques d’édition emploient _form pour les vues de création et de mise à jour et _confirm_delete pour les vues de suppression).
ListView: traitement de plusieurs objets DjangoLien vers cette rubrique#Les listes d’objets suivent grosso modo le même modèle : récupérer d’abord une liste d’objets (potentiellement paginés), typiquement un objet QuerySet, puis produire une réponse TemplateResponse avec le gabarit adéquat pour exploiter cette liste d’objets.
Pour obtenir les objets, ListView utilise MultipleObjectMixin qui offre à la fois get_queryset() et paginate_queryset(). Au contraire de SingleObjectMixin, il n’est pas nécessaire d’identifier des éléments d’URL pour déterminer le jeu de requête à traiter ; le comportement par défaut est d’utiliser l’attribut queryset ou model de la classe de vue. Une raison fréquente de vouloir surcharger ici get_queryset() est d’adapter la liste d’objets de manière dynamique, par exemple en fonction de l’utilisateur actuel ou pour exclure des articles dont la date est dans le futur dans un blog.
MultipleObjectMixin surcharge aussi get_context_data() pour inclure les variables de contexte appropriées à la pagination (indiquant des valeurs vides si la pagination est désactivée). Elle compte sur la présence de object_list dans les paramètres nommés transmis, ce dont se charge ListView.
Pour produire une réponse TemplateResponse, ListView utilise ensuite MultipleObjectTemplateResponseMixin; comme pour SingleObjectTemplateResponseMixin ci-dessus, get_template_names() est surchargée pour fournir une série d'options dont la plus utilisée est le nom de gabarit <étiquette_application>/<nom_modèle>_list.html où la partie _list provient aussi de l’attribut template_name_suffix (les vues génériques centrées sur les dates utilisent des suffixes tels que _archive, _archive_year, etc. pour utiliser différents gabarits correspondant aux différentes vues de listes spécialisées pour les dates).
Maintenant que nous avons vu comment les classes génériques fondées sur les classes de Django utilisent les mixins à disposition, examinons d’autres façons de les combiner. Nous allons toujours les combiner avec d’autres vues intégrées ou génériques fondées sur les classes, mais les cas d’utilisation auxquels Django répond ne recouvrent pas toutes les situations plus rares auxquelles on peut être confronté.
\n\nSingleObjectMixin avec ViewLien vers cette rubrique#Si nous voulons écrire une classe de vue ne répondant qu’aux requêtes POST, nous héritons de View et écrivons une méthode post() dans la sous-classe. Cependant, si le traitement doit porter sur un objet particulier identifié par l’URL, il est souhaitable de profiter de la fonctionnalité offerte par SingleObjectMixin.
Nous allons démontrer cela avec le modèle Author que nous avons utilisé dans l’introduction aux vues génériques basées sur les classes.
views.pyfrom django.http import HttpResponseForbidden, HttpResponseRedirect\nfrom django.urls import reverse\nfrom django.views import View\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Author\n\n\nclass RecordInterestView(SingleObjectMixin, View):\n """Records the current user's interest in an author."""\n\n model = Author\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n\n # Look up the author we're interested in.\n self.object = self.get_object()\n # Actually record interest somehow here!\n\n return HttpResponseRedirect(\n reverse("author-detail", kwargs={"pk": self.object.pk})\n )\nEn pratique, l’intérêt devrait probablement être enregistré dans un stockage clé-valeur plutôt que dans une base de données relationnelle, nous avons donc laissé cet aspect de côté. La seule partie de la vue qui peut profiter de l’utilisation de SingleObjectMixin est l’endroit où il s’agit de récupérer l’auteur concerné par l’intérêt, ce qui est fait en appelant self.get_object(). Tout le reste est pris en charge pour nous par le mixin.
Nous pouvons assez facilement brancher cette vue dans nos URL :
\nurls.pyfrom django.urls import path\nfrom books.views import RecordInterestView\n\nurlpatterns = [\n # ...\n path(\n "author/<int:pk>/interest/",\n RecordInterestView.as_view(),\n name="author-interest",\n ),\n]\nRemarquez le groupe nommé pk qui sera utilisé par get_object() pour rechercher l’instance Author. Il est aussi possible d’utiliser un « slug » ou toute autre fonctionnalité de SingleObjectMixin.
SingleObjectMixin avec ListViewLien vers cette rubrique#ListView intègre la pagination, mais il peut être par exemple souhatiable de paginer une liste d’objets qui sont tous liés (par clé étrangère) à un autre objet. Dans notre exemple de publication, on pourrait vouloir paginer tous les livres d’un éditeur particulier.
Une façon de faire cela serait de combiner ListView avec SingleObjectMixin, afin que le jeu de requête de la liste de livres paginée puisse dépendre de l’éditeur trouvé comme objet unique. Afin de faire cela, il est nécessaire d’avoir deux jeux de requête différents :
Book utilisé par ListViewComme nous avons accès à l’éditeur Publisher des livres que nous souhaitons afficher, nous surchargeons get_queryset() et utilisons le gestionnaire inverse de clé étrangère de l’objet Publisher.
Publisher utilisé par get_object()Nous comptons sur l’implémentation par défaut de get_object() pour récupérer le bon objet Publisher. Cependant, nous devons explicitement transmettre un paramètre queryset car sinon, l’implémentation par défaut de get_object() appellerait get_queryset() que nous avons surchargée pour renvoyer des objets Book au lieu d’objets Publisher.
Nous pouvons maintenant écrire une nouvelle vue PublisherDetailView:
from django.views.generic import ListView\nfrom django.views.generic.detail import SingleObjectMixin\nfrom books.models import Publisher\n\n\nclass PublisherDetailView(SingleObjectMixin, ListView):\n paginate_by = 2\n template_name = "books/publisher_detail.html"\n\n def get(self, request, *args, **kwargs):\n self.object = self.get_object(queryset=Publisher.objects.all())\n return super().get(request, *args, **kwargs)\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context["publisher"] = self.object\n return context\n\n def get_queryset(self):\n return self.object.book_set.all()\nRemarquez notre manière de définir self.object dans get() afin que nous puissions ensuite l’utiliser dans get_context_data() et get_queryset(). Si vous ne définissez pas template_name, le nom du gabarit prendra la valeur par défaut choisie par ListView, ce qui donnera dans ce cas "books/book_list.html" car il s’agit d’une liste de livres. ListView n’a pas conscience de la présence de SingleObjectMixin, elle ne sait donc pas du tout que cette vue a quelque chose à voir avec un objet Publisher.
Nous avons délibérément défini paginate_by à un petit nombre dans l’exemple afin que vous n’ayez pas à créer beaucoup de livres pour voir la pagination à l’œuvre ! Voici le gabarit que vous pourriez utiliser :
{% extends "base.html" %}\n\n{% block content %}\n <h2>Publisher {{ publisher.name }}</h2>\n\n <ol>\n {% for book in page_obj %}\n <li>{{ book.title }}</li>\n {% endfor %}\n </ol>\n\n <div class="pagination">\n <span class="step-links">\n {% if page_obj.has_previous %}\n <a href="?page={{ page_obj.previous_page_number }}">previous</a>\n {% endif %}\n\n <span class="current">\n Page {{ page_obj.number }} of {{ paginator.num_pages }}.\n </span>\n\n {% if page_obj.has_next %}\n <a href="?page={{ page_obj.next_page_number }}">next</a>\n {% endif %}\n </span>\n </div>\n{% endblock %}\nGénéralement, il est possible d’utiliser TemplateResponseMixin et SingleObjectMixin lorsque leurs fonctionnalités sont nécessaires. Comme montré plus haut, en prenant certaines précautions, on peut même combiner SingleObjectMixin avec ListView. Cependant, les choses deviennent de plus en plus complexes avec ces combinaisons ; voici une bonne règle générale :
Pour montrer ce qui arrive quand on essaie de trop compliquer, nous présentons un exemple qui sacrifie la lisibilité et la maintenabilité alors qu’il existe une solution plus simple. Examinons d’abord une tentative naïve de combiner DetailView avec FormMixin pour permettre l’envoi POST par un formulaire Form Django vers la même URL qui est utilisée pour afficher un objet avec DetailView.
FormMixin avec DetailViewLien vers cette rubrique#Rappelez-vous notre exemple précédent qui combinait View et SingleObjectMixin. Nous enregistrions l’intérêt d’un utilisateur pour un auteur particulier. Admettons que nous voulions maintenant donner la possibilité d’écrire un message motivant leur intérêt. Nous partons encore une fois du principe que nous ne stockerons pas cela dans une base de données relationnelle, mais plutôt dans quelque chose de plus exotique dont nous ne nous soucierons pas dans cet exemple.
À ce stade, il est naturel de faire appel à un formulaire Form pour englober les informations envoyées par le navigateur de l’utilisateur vers Django. En admettant que nous adhérons aussi aux principes de REST, nous aimerions utiliser la même URL pour l’affichage de l’auteur que pour la capture du message en provenance de l’utilisateur. Réécrivons notre vue AuthorDetailView dans cette optique.
Nous conserverons le traitement GET de la classe DetailView, même s’il faudra rajouter un formulaire Form dans les données de contexte pour pouvoir l’afficher dans le gabarit. Nous allons aussi profiter du traitement de formulaire de FormMixin et écrire un peu de code afin qu’en cas d’envoi POST, le formulaire soit instancié de manière appropriée.
Voici à quoi ressemble notre nouvelle vue AuthorDetailView:
# CAUTION: you almost certainly do not want to do this.\n# It is provided as part of a discussion of problems you can\n# run into when combining different generic class-based view\n# functionality that is not designed to be used together.\n\nfrom django import forms\nfrom django.http import HttpResponseForbidden\nfrom django.urls import reverse\nfrom django.views.generic import DetailView\nfrom django.views.generic.edit import FormMixin\nfrom books.models import Author\n\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\n\nclass AuthorDetailView(FormMixin, DetailView):\n model = Author\n form_class = AuthorInterestForm\n\n def get_success_url(self):\n return reverse("author-detail", kwargs={"pk": self.object.pk})\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n self.object = self.get_object()\n form = self.get_form()\n if form.is_valid():\n return self.form_valid(form)\n else:\n return self.form_invalid(form)\n\n def form_valid(self, form):\n # Here, we would record the user's interest using the message\n # passed in form.cleaned_data['message']\n return super().form_valid(form)\nget_success_url() sert à indiquer une destination de redirection, ce qui est utilisé dans l’implémentation par défaut de form_valid(). Nous devons fournir notre propre méthode post(), comme expliqué précédemment.
Le nombre d’interactions subtiles entre FormMixin et DetailView éprouve déjà nos capacités conceptuelles. Il est improbable que vous ayez envie d’écrire vous-même ce genre de classe.
Dans ce cas, vous pourriez écrire vous-même la méthode post(), en conservant DetailView comme seule fonctionnalité générique, même si l’écriture du code de gestion des formulaires implique beaucoup de duplication.
Sinon, une approche certainement plus économique que ci-dessus serait d’avoir une vue séparée pour le traitement du formulaire, ce qui permettrait d’utiliser sans problème FormView séparément de DetailView.
En réalité, ce que nous essayons de faire ici est d’utiliser deux vues classes différentes pour la même URL. Pourquoi donc ne pas simplement faire cela ? La division est ici très claire : les requêtes GET devraient aboutir à la vue DetailView (avec en plus le formulaire dans les données de contexte) et les requêtes POST à la vue FormView. Mettons d’abord en place ces deux vues.
La vue AuthorDetailView est presque la même que celle que nous avons présentée en introduction. Nous devons écrire notre propre méthode get_context_data() pour mettre à disposition AuthorInterestForm dans le gabarit. Nous omettons la surcharge de get_object() de la version précédente par souci de clarté :
from django import forms\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\n\nclass AuthorInterestForm(forms.Form):\n message = forms.CharField()\n\n\nclass AuthorDetailView(DetailView):\n model = Author\n\n def get_context_data(self, **kwargs):\n context = super().get_context_data(**kwargs)\n context["form"] = AuthorInterestForm()\n return context\nPuis pour AuthorInterestFormView, il s’agit d’une sous-classe de FormView, mais nous devons y adjoindre SingleObjectMixin pour pouvoir obtenir l’auteur concerné par l’action en cours et ne pas oublier de définir template_name pour s’assurer que les erreurs de formulaires soient affichées dans le même gabarit que AuthorDetailView utilise lors de la requête GET:
from django.http import HttpResponseForbidden\nfrom django.urls import reverse\nfrom django.views.generic import FormView\nfrom django.views.generic.detail import SingleObjectMixin\n\n\nclass AuthorInterestFormView(SingleObjectMixin, FormView):\n template_name = "books/author_detail.html"\n form_class = AuthorInterestForm\n model = Author\n\n def post(self, request, *args, **kwargs):\n if not request.user.is_authenticated:\n return HttpResponseForbidden()\n self.object = self.get_object()\n return super().post(request, *args, **kwargs)\n\n def get_success_url(self):\n return reverse("author-detail", kwargs={"pk": self.object.pk})\nPour terminer, nous lions le tout en créant une nouvelle vue AuthorView. Nous savons déjà que l’appel à as_view() sur une vue fondée sur les classes nous renvoie un objet se comportant exactement comme une vue de type fonction. Nous pouvons donc effectuer cet appel au moment où il faut choisir entre les deux « sous-vues ».
Vous pouvez transmettre des paramètres nommés à as_view() comme vous le feriez dans la configuration d’URL, par exemple si vous vouliez que le comportement de AuthorInterestFormView puisse aussi être utilisé avec une autre URL mais en affichant un gabarit différent :
from django.views import View\n\n\nclass AuthorView(View):\n def get(self, request, *args, **kwargs):\n view = AuthorDetailView.as_view()\n return view(request, *args, **kwargs)\n\n def post(self, request, *args, **kwargs):\n view = AuthorInterestFormView.as_view()\n return view(request, *args, **kwargs)\nCette approche peut également être employée avec toute autre vue fondée sur les classes, générique ou créée par vos soins, héritant directement de View ou de TemplateView, car elle conserve les différentes vues aussi distinctes que possible.
Les vues fondées sur les classes se révèlent particulièrement utiles au moment où l’on a besoin de répéter plusieurs fois un processus semblable. Imaginez qu’il faille écrire une API et que chaque vue doive renvoyer du JSON au lieu de produire une page HTML.
\nIl est alors possible de créer une classe mixin afin de l’utiliser dans chaque vue, gérant ainsi à un seul endroit la conversion vers le format JSON.
\nPar exemple, une classe mixin pour JSON pourrait ressembler à ceci :
\nfrom django.http import JsonResponse\n\n\nclass JSONResponseMixin:\n """\n A mixin that can be used to render a JSON response.\n """\n\n def render_to_json_response(self, context, **response_kwargs):\n """\n Returns a JSON response, transforming 'context' to make the payload.\n """\n return JsonResponse(self.get_data(context), **response_kwargs)\n\n def get_data(self, context):\n """\n Returns an object that will be serialized as JSON by json.dumps().\n """\n # Note: This is *EXTREMELY* naive; in reality, you'll need\n # to do much more complex handling to ensure that arbitrary\n # objects -- such as Django model instances or querysets\n # -- can be serialized as JSON.\n return context\nCe mixin fournit une méthode render_to_json_response() ayant la même signature que render_to_response(). Pour l’utiliser, nous devons la combiner par exemple à une classe TemplateView et surcharger render_to_response() afin d’appeler render_to_json_response() à la place :
from django.views.generic import TemplateView\n\n\nclass JSONView(JSONResponseMixin, TemplateView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nIl serait aussi possible d’utiliser cette classe mixin avec l’une des vues génériques. On peut composer sa propre version de DetailView en combinant JSONResponseMixin avec BaseDetailView (celle-ci contenant le comportement de DetailView avant le rendu du gabarit) :
from django.views.generic.detail import BaseDetailView\n\n\nclass JSONDetailView(JSONResponseMixin, BaseDetailView):\n def render_to_response(self, context, **response_kwargs):\n return self.render_to_json_response(context, **response_kwargs)\nCette vue peut ensuite être déployée de la même façon que pour n’importe quelle vue DetailView, reproduisant le même comportement à l’exception du format de la réponse.
Si vous avez de réels goûts d’aventure, vous pourriez même tenter de combiner avec une sous-classe de DetailView capable de renvoyer à la fois du contenu HTML et JSON en fonction d’une propriété de la requête HTTP, telle qu’un paramètre de requête ou un en-tête HTTP. Combinez JSONResponseMixin avec SingleObjectTemplateResponseMixin et surchargez l’implémentation de render_to_response() pour déléguer le rendu à la méthode appropriée en fonction du type de réponse demandée par l’utilisateur :
from django.views.generic.detail import SingleObjectTemplateResponseMixin\n\n\nclass HybridDetailView(\n JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView\n):\n def render_to_response(self, context):\n # Look for a 'format=json' GET argument\n if self.request.GET.get("format") == "json":\n return self.render_to_json_response(context)\n else:\n return super().render_to_response(context)\nEn raison de la façon dont Python résout la surcharge des méthodes, l’appel à super().render_to_response(context) fait en réalité appel à l’implémentation render_to_response() de TemplateResponseMixin.