L’écriture d’applications Web peut être une tâche monotone, car certains motifs se répètent encore et encore. Django essaie d’enlever une partie de cette monotonie au niveau des modèles et des gabarits, mais les développeurs Web font également face à ces répétitions au niveau des vues.
\nLes vues génériques de Django ont été développées pour résoudre ce problème. 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 écrire trop de code.
\nIl est possible d’identifier certaines tâches courantes, comme l’affichage d’une liste d’objets, et d’écrire du code qui affiche une liste de n’importe quel objet. Puis, le modèle concerné peut être transmis comme paramètre supplémentaire dans la configuration d’URL.
\nDjango est livré avec des vues génériques pour accomplir les choses suivantes :
\nAfficher des pages de liste et de détail pour un seul type d’objet. Si nous devions créer une application pour gérer des conférences, une vue TalkListView et une vue RegisteredUserListView seraient des exemples de vues de listes. Une page d’une seule conférence pourrait être un exemple de ce que nous appelons une vue de « détail ».
Présenter des objets datés dans des pages d’archive par année/mois/jour, avec les détails associés et des pages « éléments récents ».
Permettre à des utilisateurs de créer, mettre à jour et supprimer des objets, avec ou sans gestion des autorisations.
Considérées globalement, ces vues offrent des interfaces pour effectuer les tâches les plus courantes que rencontrent les développeurs.
\nIl est indiscutable que l’utilisation des vues génériques peut considérablement accélérer le développement. Dans la plupart des projets, cependant, on atteint souvent un stade où les vue génériques ne suffisent plus. En fait, la question la plus fréquemment posée par les nouveaux développeurs Django est de savoir comment il est possible de gérer plus de variétés de situations avec les vues génériques.
\nC’est l’une des raisons pour lesquelles les vues génériques ont été revues pour la version 1.3 ; précédemment, il s’agissait de fonctions de vue avec une très large diversité d’options. Maintenant, au lieu de transmettre une grosse partie de configuration dans la configuration d’URL, la manière recommandée d’étendre les vues génériques est d’en faire des sous-classes et de surcharger leurs attributs et méthodes.
\nCeci dit, les vues génériques ont leurs limites. Si vous vous retrouvez à vous battre pour implémenter vos vues comme des sous-classes de vues génériques, il se pourrait qu’il soit plus efficace d’écrire simplement le code dont vous avez besoin dans vos vues, que ce soit par des fonctions ou des classes.
\nVous trouverez davantage d’exemples de vues génériques dans certaines applications tierces, mais n’hésitez pas à écrire vos propres vues selon vos besoins.
\nTemplateView est certainement utile, mais les vues génériques de Django exposent tout leur potentiel lorsqu’il s’agit de présenter des vues de contenu de la base de données. Dans la mesure où c’est une tâche très courante, Django contient un ensemble de vues génériques intégrées pour aider à générer des vues de liste et de détail pour les objets.
Commençons par examiner quelques exemples d’affichage d’une liste d’objets ou d’un objet individuel.
\nNous allons utiliser ces modèles :
\n# models.py\nfrom django.db import models\n\nclass Publisher(models.Model):\n name = models.CharField(max_length=30)\n address = models.CharField(max_length=50)\n city = models.CharField(max_length=60)\n state_province = models.CharField(max_length=30)\n country = models.CharField(max_length=50)\n website = models.URLField()\n\n class Meta:\n ordering = ["-name"]\n\n def __str__(self):\n return self.name\n\nclass Author(models.Model):\n salutation = models.CharField(max_length=10)\n name = models.CharField(max_length=200)\n email = models.EmailField()\n headshot = models.ImageField(upload_to='author_headshots')\n\n def __str__(self):\n return self.name\n\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n authors = models.ManyToManyField('Author')\n publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)\n publication_date = models.DateField()\nNous devons maintenant définir une vue :
\n# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\nclass PublisherListView(ListView):\n model = Publisher\nEt finalement connecter cette vue à une URL :
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherListView\n\nurlpatterns = [\n path('publishers/', PublisherListView.as_view()),\n]\nVoilà tout le code Python qu’il suffit d’écrire. Il faut cependant encore écrire un gabarit. Nous pourrions indiquer explicitement à la vue le gabarit à utiliser en lui ajoutant un attribut template_name, mais en l’absence d’un gabarit explicite, Django déduit un nom de gabarit à partir du nom de l’objet. Dans ce cas, le gabarit « automatique » sera "books/publisher_list.html", la partie « books » provient du nom de l’application contenant ce modèle alors que « publisher » provient du nom du modèle en minuscules.
Ce gabarit sera rendu avec un contexte contenant une variable appelée object_list contenant elle-même les objets Publisher. Un gabarit pourrait ressembler à ceci :
{% extends "base.html" %}\n\n{% block content %}\n <h2>Publishers</h2>\n <ul>\n {% for publisher in object_list %}\n <li>{{ publisher.name }}</li>\n {% endfor %}\n </ul>\n{% endblock %}\nEt voilà, tout est là. Toutes les fonctionnalités sympathiques des vues génériques proviennent des modifications d’attributs définis dans la vue générique. La référence des vues génériques documente en détails toutes les vues génériques et leurs options. La suite de de document s’attelle à décrire certaines manières fréquentes de personnaliser et étendre les vues génériques.
\nVous avez peut-être constaté que notre exemple de gabarit de liste d’éditeurs stocke tous les éditeurs dans une variable nommée object_list. Même si cela fonctionne très bien, ce n’est pas très « sympa » pour les auteurs de gabarits : ils doivent simplement savoir qu’ils manipulent ici des éditeurs.
Si vous avez affaire à un objet de modèle, c’est déjà fait pour vous. Lorsque vous avez affaire à un objet ou un jeu de requête, Django est capable de renseigner le contexte en utilisant la version en minuscules du nom de la classe de modèle. Ceci s’ajoute à l’élément object_list par défaut, mais contient exactement les mêmes données, c’est-à-dire publisher_list.
Si ce n’est toujours pas un bon nom, vous pouvez indiquer explicitement le nom de la variable de contexte. L’attribut context_object_name d’une vue générique indique le nom de variable de contexte à utiliser :
# views.py\nfrom django.views.generic import ListView\nfrom books.models import Publisher\n\nclass PublisherListView(ListView):\n model = Publisher\n context_object_name = 'my_favorite_publishers'\nLa mise à disposition d’un nom context_object_name signifiant est toujours une bonne idée. Vos collaborateurs rédacteurs de gabarits vous remercieront.
Il est souvent nécessaire de compléter par quelques informations supplémentaires au-delà de ce que la vue générique fournit. Par exemple, on peut penser à afficher une liste de livres sur la page de détail des éditeurs. La vue générique DetailView place l’éditeur dans le contexte, mais comment ajouter d’autres informations dans le gabarit ?
La réponse consiste à créer une sous-classe de DetailView et d’y placer votre propre implémentation de la méthode get_context_data. L’implémentation par défaut ajoute l’objet à afficher dans le gabarit, mais en la surchargeant, vous pouvez l’enrichir :
from django.views.generic import DetailView\nfrom books.models import Book, Publisher\n\nclass PublisherDetailView(DetailView):\n\n model = Publisher\n\n def get_context_data(self, **kwargs):\n # Call the base implementation first to get a context\n context = super().get_context_data(**kwargs)\n # Add in a QuerySet of all the books\n context['book_list'] = Book.objects.all()\n return context\nExaminons maintenant un peu plus attentivement le paramètre model que nous avons toujours utilisé. Ce paramètre, qui définit le modèle de base de données sur lequel la vue va porter, est disponible pour toutes les vues génériques qui opèrent sur un seul objet ou une liste d’objets. Cependant, le paramètre model n’est pas le seul moyen de définir le type d’objet d’une vue, il est aussi possible de définir la liste des objets par le paramètre queryset:
from django.views.generic import DetailView\nfrom books.models import Publisher\n\nclass PublisherDetailView(DetailView):\n\n context_object_name = 'publisher'\n queryset = Publisher.objects.all()\nL’indication de model = Publisher est un raccourci pour dire queryset = Publisher.objects.all(). Cependant, en utilisant queryset pour définir une liste d’objets filtrée, vous pouvez spécifier plus finement les objets qui seront visibles dans la vue (voir Création de requêtes pour plus d’informations à propos des objets QuerySet, et consultez la référence des vues fondées sur les classes pour obtenir tous les détails).
Comme exemple, essayons de trier une liste de livres par date de publication, les plus récents en premier :
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass BookListView(ListView):\n queryset = Book.objects.order_by('-publication_date')\n context_object_name = 'book_list'\nIl s’agit d’un exemple très minimal, mais qui montre bien le principe de fonctionnement. Le but est généralement de faire plus que de simplement trier les objets. Si vous souhaitez présenter une liste de livres provenant d’un éditeur particulier, la même technique peut être utilisée :
\nfrom django.views.generic import ListView\nfrom books.models import Book\n\nclass AcmeBookListView(ListView):\n\n context_object_name = 'book_list'\n queryset = Book.objects.filter(publisher__name='ACME Publishing')\n template_name = 'books/acme_list.html'\nRemarquez qu’en plus d’un paramètre queryset filtré, nous indiquons également un nom de gabarit personnalisé. Sans cela, la vue générique utiliserait le même gabarit que la liste d’objets « standard », ce qui ne correspondrait pas au but recherché.
Remarquez également que ce n’est pas une façon très élégante d’afficher les livres d’un éditeur particulier. Si nous voulions ensuite ajouter une page pour un autre éditeur, nous devrions ajouter des lignes supplémentaires dans la configuration d’URL et nous serions pratiquement limités à quelques éditeurs. Nous aborderons ce problème dans la section suivante.
\n\nUn autre besoin fréquent est de filtrer les objets d’une liste selon un critère de l’URL. Plus haut, nous avons figé le nom de l’éditeur dans la configuration d’URL, mais comment faire si nous voulions écrire une vue affichant tous les livres d’un éditeur librement choisi ?
\nHeureusement, la classe ListView possède une méthode get_queryset() que nous pouvons surcharger. Par défaut, elle renvoie la valeur du paramètre queryset, mais on peut l’utiliser pour ajouter de la logique supplémentaire.
L’élément clé pour que cela fonctionne est qu’au moment où les vues fondées sur les classes sont appelées, divers attributs utiles sont créés pour self. En plus de la requête elle-même (self.request), il y a aussi les paramètres positionnels (self.args) et nommés (self.kwargs) capturés en fonction de la configuration d’URL.
Ici, nous avons une configuration d’URL comportant un seul groupe capturé :
\n# urls.py\nfrom django.urls import path\nfrom books.views import PublisherBookListView\n\nurlpatterns = [\n path('books/<publisher>/', PublisherBookListView.as_view()),\n]\nPuis, nous allons écrire la vue PublisherBookListView:
# views.py\nfrom django.shortcuts import get_object_or_404\nfrom django.views.generic import ListView\nfrom books.models import Book, Publisher\n\nclass PublisherBookListView(ListView):\n\n template_name = 'books/books_by_publisher.html'\n\n def get_queryset(self):\n self.publisher = get_object_or_404(Publisher, name=self.kwargs['publisher'])\n return Book.objects.filter(publisher=self.publisher)\nUtiliser get_queryset pour ajouter de la logique à la sélection du jeu de requête est aussi pratique que puissant. Nous pourrions par exemple filtrer en se basant sur l’utilisateur connecté (self.request.user) ou toute autre logique plus complexe.
Nous pouvons aussi ajouter en même temps l’éditeur dans le contexte, afin de pouvoir l’utiliser dans le gabarit :
\n# ...\n\ndef get_context_data(self, **kwargs):\n # Call the base implementation first to get a context\n context = super().get_context_data(**kwargs)\n # Add in the publisher\n context['publisher'] = self.publisher\n return context\nLe dernier usage que nous examinerons concerne les opérations supplémentaires effectuées avant ou après l’appel à la vue générique.
\nImaginez que nous ayons un champ last_accessed dans le modèle Author qui nous sert à garder la trace du moment le plus récent où quelqu’un a consulté la page de cet auteur :
# models.py\nfrom django.db import models\n\nclass Author(models.Model):\n salutation = models.CharField(max_length=10)\n name = models.CharField(max_length=200)\n email = models.EmailField()\n headshot = models.ImageField(upload_to='author_headshots')\n last_accessed = models.DateTimeField()\nLa classe générique DetailView n’a aucune conscience de la présence de ce champ, mais nous pouvons une nouvelle fois écrire une vue personnalisée pour maintenir ce champ à jour.
Tout d’abord, nous devons ajouter une ligne de détail d’auteur dans la configuration d’URL pour faire le lien avec une vue personnalisée :
\nfrom django.urls import path\nfrom books.views import AuthorDetailView\n\nurlpatterns = [\n #...\n path('authors/<int:pk>/', AuthorDetailView.as_view(), name='author-detail'),\n]\nPuis il s’agit d’écrire la nouvelle vue. get_object étant la méthode qui récupère l’objet, nous la surchargeons en « enveloppant » l’appel par défaut :
from django.utils import timezone\nfrom django.views.generic import DetailView\nfrom books.models import Author\n\nclass AuthorDetailView(DetailView):\n\n queryset = Author.objects.all()\n\n def get_object(self):\n obj = super().get_object()\n # Record the last accessed date\n obj.last_accessed = timezone.now()\n obj.save()\n return obj\n