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 ?
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 :
- Gestion des autorisations : Vérifiez si l'utilisateur accédant à une vue est connecté ou possède une autorisation spécifique.
- Logique de traitement des formulaires : Prétraitement ou post-traitement des données nécessaires dans plusieurs formulaires.
- Contexte de template : Ajoutez des données de contexte qui doivent être transmises à toutes les vues.
- 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 (iciListView
). 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 parsettings.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êtenext
.
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.
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'applicationauth
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>© {{ current_year }} Mon Site Web</footer>
- Le
CurrentYearMixin
surcharge la méthodeget_context_data
pour ajoutercurrent_year
au contexte. Il est important d'appelersuper().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
- Exploration des vues basées sur les classes (CBV) #1 - Pourquoi passer de FBV à CBV et l'attitude des développeurs
- Exploration des vues basées sur les classes (CBV) #2 - Comprendre la classe de vue de base de Django
- Exploration des vues basées sur les classes (CBV) #3 - Simplifier le traitement des formulaires avec FormView
- Exploration des vues basées sur les classes (CBV) #4 - Utilisation de ListView & DetailView
- Exploration des vues basées sur les classes (CBV) #5 - Implémenter CRUD avec CreateView, UpdateView, et DeleteView
- 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 !”
Aucun commentaire.