Le texte ci-dessous est la 7ème partie de la série d'exploration des vues basées sur les classes (CBV) de Django, où nous allons aborder comment utiliser les Mixins pour réutiliser des fonctionnalités communes, ainsi que pour mettre en œuvre efficacement la gestion des autorisations et la vérification de connexion. Dans l'article précédent (6ème partie), nous avons automatisé le rendu de pages simples et la redirection avec TemplateView et RedirectView. Maintenant, découvrons comment maximiser la réutilisabilité et l'extensibilité des CBV.

Pour lire le dernier article, cliquez sur le lien ci-dessous !

Utilisation de TemplateView & RedirectView


“Augmentez la réutilisabilité du code avec Django Mixin et implémentez facilement la vérification de connexion et la gestion des autorisations !”


1. Mixin, pourquoi est-ce nécessaire ?

Concept de Mixin – Structure de classe avec des blocs fonctionnels assemblés

Les CBV de Django offrent un fort potentiel de réutilisation, mais que faire s'il existe des fonctionnalités dont plusieurs vues ont besoin ? Par exemple, dans de nombreux cas, un authentification est requise pour accéder à une certaine page, ou seulement les utilisateurs possédant une autorisation spécifique peuvent y accéder. C'est là qu'interviennent les Mixins.

Un Mixin utilise le concept de héritage multiple pour injecter les mêmes méthodes ou propriétés dans plusieurs classes. Dans les CBV de Django, en héritant d'une classe Mixin qui implémente certaines fonctionnalités, on peut réduire le code dupliqué et améliorer la maintenabilité.

Exemples d'utilisation courante des Mixins :

  1. Gestion des autorisations : Vérifiez si l'utilisateur accédant à une vue est connecté ou possède une autorisation spécifique.
  2. Logique de traitement des formulaires : Prétraitement ou post-traitement des données nécessaires dans plusieurs formulaires.
  3. Contexte de template : Ajoutez des données de contexte qui doivent être transmises à toutes les vues.
  4. Journalisation : Ajoutez la fonctionnalité de journalisation avant et après l'exécution d'une vue spécifique.

2. Exemple typique d'utilisation des Mixins dans Django : LoginRequiredMixin

Un des Mixins les plus couramment utilisés est LoginRequiredMixin. Comme son nom l'indique, il force l'authentification pour accéder à la vue.

2.1 Utilisation de LoginRequiredMixin

LoginRequiredMixin est inclus dans le module django.contrib.auth.mixins.

# views.py
from django.views.generic import ListView
from django.contrib.auth.mixins import LoginRequiredMixin
from .models import Post # Modèle d'exemple

class MyPostListView(LoginRequiredMixin, ListView):
    model = Post
    template_name = 'posts/my_posts.html'
    context_object_name = 'posts'

    # URL vers laquelle rediriger si l'utilisateur n'est pas connecté (optionnel)
    # login_url = '/accounts/login/' # par défaut settings.LOGIN_URL
    # redirect_field_name = 'next'  # nom du paramètre de requête utilisé pour revenir à la page d'origine après connexion (par défaut)
  • Ordre d'héritage: Héritez d'abord de LoginRequiredMixin, puis de la Vue Générique de Django (ici ListView). Les Mixins sont généralement utilisés pour ajouter des fonctionnalités, donc il est de coutume de les placer avant la classe de vue principale.
  • LoginRequiredMixin redirige automatiquement vers la page de connexion spécifiée par settings.LOGIN_URL si l'utilisateur n'est pas connecté. En cas de succès de la connexion, l'utilisateur est redirigé vers la page qu'il avait initialement demandée par le biais du paramètre de requête next.

2.2 Liaison avec urls.py

Les vues avec LoginRequiredMixin se lient à urls.py de la même manière que les CBV ordinaires.

# urls.py
from django.urls import path
from .views import MyPostListView

urlpatterns = [
    path('my-posts/', MyPostListView.as_view(), name='my_posts'),
]

Maintenant, lorsque vous accédez au chemin /my-posts/, si vous n'êtes pas connecté, vous serez redirigé vers la page de connexion.


3. Mixins pour la gestion des autorisations : PermissionRequiredMixin & UserPassesTestMixin

Si LoginRequiredMixin impose la connexion, les Mixins PermissionRequiredMixin et UserPassesTestMixin permettent l'accès uniquement aux utilisateurs ayant une autorisation spécifique ou remplissant certaines conditions.

Concept Login & PermissionMixin – Vérification des autorisations d'accès

3.1 Utilisation de PermissionRequiredMixin

Il permet l'accès uniquement aux utilisateurs possédant un permission correspondant au système d'autorisations de Django.

# views.py
from django.views.generic import CreateView
from django.contrib.auth.mixins import PermissionRequiredMixin
from .models import Article
from .forms import ArticleForm

class ArticleCreateView(PermissionRequiredMixin, CreateView):
    model = Article
    form_class = ArticleForm
    template_name = 'articles/article_form.html'
    success_url = '/articles/'

    # Spécifiez les autorisations sous la forme 'app_label.permission_codename'
    permission_required = 'app_label.add_article'
    # Si l'un des multiples droits est requis :
    # permission_required = ('app_label.add_article', 'app_label.change_article')
    # raise_exception = True # Lancer une erreur 403 Forbidden si aucune autorisation (par défaut redirige vers la page de connexion)
  • permission_required: spécifiez l'autorisation requise sous forme de chaîne (ou tuple). Les autorisations générées automatiquement par l'application auth de Django (add_model, change_model, delete_model, view_model) sont principalement utilisées.

3.2 Utilisation de UserPassesTestMixin

Utilisé pour vérifier des conditions plus complexes ou personnalisées. Par exemple, pour permettre la modification uniquement des articles écrits par l'utilisateur ou pour restreindre l'accès à des utilisateurs d'un groupe spécifique.

# views.py
from django.views.generic import UpdateView
from django.contrib.auth.mixins import UserPassesTestMixin
from .models import Comment
from .forms import CommentForm

class CommentUpdateView(UserPassesTestMixin, UpdateView):
    model = Comment
    form_class = CommentForm
    template_name = 'comments/comment_form.html'
    success_url = '/comments/'

    # Override la méthode test_func pour vérifier des conditions
    def test_func(self):
        comment = self.get_object()
        # Vérifiez si l'utilisateur actuellement connecté est l'auteur du commentaire
        return self.request.user == comment.author or self.request.user.is_superuser

    # raise_exception = True # Lancer une erreur 403 Forbidden si le test échoue
  • En surchargeant la méthode test_func(), retourner True permet d'accorder l'accès, tandis qu'un retour de False le refuse.
  • Vous pouvez accéder à l'objet utilisateur connecté actuellement via self.request.user.

4. Création de Mixins personnalisés

En plus des Mixins fournis par Django, vous pouvez créer vos propres Mixins à réutiliser dans plusieurs vues. Par exemple, créons un Mixin qui ajoute le contexte current_year nécessaire sur toutes les pages.

# common/mixins.py
from datetime import datetime

class CurrentYearMixin:
    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context['current_year'] = datetime.now().year
        return context

# views.py (Exemple d'application)
from django.views.generic import TemplateView
from .common.mixins import CurrentYearMixin

class MyCustomPageView(CurrentYearMixin, TemplateView):
    template_name = 'my_custom_page.html'

# my_custom_page.html (Utilisation dans le template)
<footer>&copy; {{ current_year }} Mon Site Web</footer>
  • Le CurrentYearMixin surcharge la méthode get_context_data pour ajouter current_year au contexte. Il est important d'appeler super().get_context_data(**kwargs) pour maintenir les données de contexte de la classe parente (ou d'autres Mixins).

5. Comparaison avec FBV

Fonctionnalité FBV (Vue Basée sur les Fonctions) CBV + Mixin
Vérification de connexion/autorisation Utilisation de décorateurs @login_required, @permission_required. <br> Les conditions personnalisées doivent être écrites directement dans la fonction comme if not request.user.is_authenticated: return redirect(...). Application simple par héritage de LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin etc. <br> Similaire aux décorateurs, mais plus intégré à la structure CBV.
Réutilisabilité du code Séparer la logique commune en une fonction distincte ou créer des décorateurs de fonction. <br> Risque de code dupliqué. Modularisation des fonctionnalités requises via Mixin et injection par héritage multiple. <br> Bien plus structuré et réutilisable.
Lisibilité du code La logique de vérification des conditions peut se répéter dans chaque fonction. Il est facile d'identifier les fonctions (permissions, connexion, etc.) appliquées juste en regardant la liste des héritages de la classe de vue.
Maintenabilité Ajouter de nouvelles fonctionnalités peut nécessiter de modifier plusieurs fonctions. Modifier uniquement la classe Mixin met à jour toutes les vues utilisant ce Mixin.
Productivité de développement (mots clés clés) "Traitement individuel par fonction, répétition des tâches possible" "Modularisation, facilité d'expansion des fonctionnalités, respect du principe DRY (Don't Repeat Yourself), amélioration de la productivité"

6. Conclusion et aperçu du prochain article

Le Mixin est un élément clé qui fait émerger la vraie puissance des vues basées sur les classes de Django. Grâce à cela, nous pouvons maximaliser la réutilisabilité du code et modulariser les fonctionnalités communes, réduisant ainsi la complexité des classes de vue, et en particulier, mettre en œuvre des éléments essentiels d'une application web, comme l'authentification et la gestion des autorisations, de manière très efficace.

Nous avons maintenant exploré presque tous les aspects essentiels de Django CBV, depuis les bases d'utilisation jusqu'aux opérations CRUD complexes, ainsi que l'expansion des fonctionnalités via des Mixins.

Dans l'article suivant (série 8), nous expliquerons comment appliquer les CBV étudiés dans des projets réels, comment les combiner dans des scénarios complexes, et nous ferons un récapitulatif complet des avantages et des limites des CBV.


Voir les articles précédents

  1. Exploration des vues basées sur les classes (CBV) #1 - Pourquoi passer de FBV à CBV et l'attitude des développeurs
  2. Exploration des vues basées sur les classes (CBV) #2 - Comprendre la classe de vue de base de Django
  3. Exploration des vues basées sur les classes (CBV) #3 - Simplifier le traitement des formulaires avec FormView
  4. Exploration des vues basées sur les classes (CBV) #4 - Utilisation de ListView & DetailView
  5. Exploration des vues basées sur les classes (CBV) #5 - Implémenter CRUD avec CreateView, UpdateView, et DeleteView
  6. Exploration des vues basées sur les classes (CBV) #6 - Utilisation de TemplateView & RedirectView

“Exploitez pleinement le potentiel des CBV de Django avec Mixin et construisez des applications Web faciles à maintenir et extensibles !”