Allez plus loin avec le framework Django

Refactorisez la vue de connexion pour en faire une vue basée sur une classe

Notre prochaine étape ? Vous allez recréer la fonctionnalité du chapitre précédent en utilisant des vues basées sur des classes !

Qu’est-ce que c’est qu’une vue basée sur une classe ?

Comme vous l’avez peut-être deviné, les vues basées sur des classes représentent les vues par le biais de classes plutôt que de fonctions.

De base, les vues basées sur des classes divisent les différentes fonctionnalités d’une vue — par exemple, la façon dont elle répond aux requêtes  GET  par opposition aux requêtes  POST  — en différentes méthodes.

Voyons en vidéo comment convertir la vuelogin_page, basée sur une fonction, en vue basée sur une classe.

Étape 1 : Refactorisez la vue de connexion basée sur une fonction en vue basée sur une classe

Tout d’abord, intéressons-nous à la vue de connexion actuelle.

def login_page(request):
    form = forms.LoginForm()
    message = ''
    if request.method == 'POST':
        form = forms.LoginForm(request.POST)
        if form.is_valid():
            user = authenticate(
                username=form.cleaned_data['username'],
                password=form.cleaned_data['password'],
            )
            if user is not None:
                login(request, user)
                return redirect('home')
        message = 'Identifiants invalides.'
    return render(request, 'authentication/login.html', context={'form': form, 'message': message})

 Pour l’instant, cette fonction est exécutée quelle que soit la méthode de requête. Seul le code sous l’instruction  if request.method == 'POST'   est exclusif aux requêtes  POST  .

Et maintenant, regardons-la en tant que vue basée sur la classe :

from django.views.generic import View


class LoginPageView(View):
    template_name = 'authentication/login.html'
    form_class = forms.LoginForm

    def get(self, request):
        form = self.form_class()
        message = ''
        return render(request, self.template_name, context={'form': form, 'message': message})
        
    def post(self, request):
        form = self.form_class(request.POST)
        if form.is_valid():
            user = authenticate(
                username=form.cleaned_data['username'],
                password=form.cleaned_data['password'],
            )
            if user is not None:
                login(request, user)
                return redirect('home')
        message = 'Identifiants invalides.'
        return render(request, self.template_name, context={'form': form, 'message': message})

 Comme vous pouvez le constater, la logique de la vue est maintenant proprement divisée en méthodes  get  et   post. Nous avons également pris certains éléments réutilisés pour les définir comme attributs de classe. L’avantage de ce procédé est double. Premièrement, il vous permet de changer facilement ces attributs à partir d’un même endroit, ce qui rend le code plus maintenable. Deuxièmement, il permet, via l’héritage, le remplacement facile de gabarit et de formulaire, ce qui rend la classe flexible et extensible !

Étape 2 : Ajoutez la vue basée sur une classe comme modèle d’URL

Pour inclure une vue basée sur une classe dans un modèle d’URL, utilisez la méthode  as_view(). C’est l’une des méthodes utilitaires auxquelles vous avez accès grâce à l’héritage dedjango.views.View.

# fotoblog/urls.py

urlpatterns = [
    ...
    path('', authentication.views.LoginPageView.as_view(), name='login'),
    ...
]

Peut-être qu’en créant des vues basées sur des classes, vous voudrez restreindre la vue aux utilisateurs connectés à votre site. La façon la plus facile de le faire est de faire hériter votre vue de  django.contrib.auth.mixins.LoginRequiredMixin, en plus de la  View  de base.

Et c’est aussi simple que ça ! Si vous avez décidé de coder en suivant cette section, essayez la fonctionnalité de connexion maintenant.

Implémentez la connexion avec des vues génériques

Les vues basées sur des classes ont été imaginées pour créer des vues génériques plus facilement extensibles et flexibles. L’objectif des vues génériques est de réduire la quantité de code communément répété entre différentes vues.

Par exemple, si vous voulez que votre vue affiche des informations sur une instance spécifique d’un modèle, vous pouvez utiliser uneDetailView. Si vous voulez lister toutes les instances d’un modèle, vous pouvez utiliser uneListView.

Vous l’avez peut-être deviné : vous pouvez aussi utiliser ces vues génériques pour gérer l’authentification ! Les chapitres précédents vous ont apporté des éclaircissements sur certains fonctionnements bas niveau de l’authentification. Dans le cadre d’un autre projet, la facilité et la simplicité des vues d’authentification génériques vous conviendront peut-être mieux.

Reconstruisons notre système d’authentification avec des vues génériques. L'explication en vidéo :

Nous allons utiliser la vue LoginView  générique , qui se trouve dans  django.auth.views. Avec la LoginView, toute la logique de la vue est déjà gérée. Vous n’avez qu’à écrire un gabarit et vous assurer que la configuration nécessaire est en place.

Les étapes clés pour recréer la fonctionnalité de connexion avec la  LoginView  sont les suivantes :

• Implémentez un gabarit qui inclut un formulaire avec la variable   form.

• Passez ce gabarit à la méthode  LoginView.as_view() , via le paramètre   template_name.

• Configurez la page de connexion pour qu’elle redirige automatiquement les utilisateurs connectés, en passant l’argument nommé  redirect_authenticated_user=True  à    LoginView.as_view()  . 

• Dans les paramètres, réglez   LOGIN_REDIRECT_URL  sur la page de redirection réussie. 

Il semblerait que le gabarit que vous utilisez déjà pour votre page de connexion fonctionnera très bien !

Mettons maintenant ces étapes en pratique pour implémenter  LoginView  .

Étape 1 : Configurez les paramètres

Ajoutez  LOGIN_REDIRECT_URL  aux paramètres.

# fotoblog/settings.py

LOGIN_REDIRECT_URL = 'home'

Étape 2 : Ajoutez le modèle d’URL et la configuration de la vue

Comme l’ensemble de la logique de la vue est déjà géré par la  LoginView  générique, vous n’avez pas besoin d’implémenter la vue dans  views.py  . Ajoutez-la directement dans  urls.py   avec la configuration nécessaire.

# authentication/urls.py
from django.contrib.auth.views import LoginView
    
urlpatterns = [
    path('', LoginView.as_view(
            template_name='authentication/login.html',
            redirect_authenticated_user=True),
        name='login'),
    path('logout/', authentication.views.logout_user, name='logout'),
]

 Et c’est tout ! Vous pouvez même supprimer le fichier  forms.py  , vu que nous n’utilisons plus  LoginForm  .

Essayez de tester la fonctionnalité de connexion maintenant. Normalement, elle devrait fonctionner de la même façon qu’avant.

Vous savez désormais comment utiliser une vue générique : il est temps de vous lancer dans l’implémentation vous-même !

C'est à vous ! Implémentez des vues d’authentification génériques

La  LoginView   n’est pas la seule vue d’authentification fournie par Django. Il y a toute une série de vues génériques.

Pour cet exercice, implémentez les vues suivantes, qui se trouvent dans  django.contrib.auth.views  :

• LogoutView  (vue de déconnexion) — vous pouvez supprimer la vue   logout_user  que nous avions construite une fois que c’est fait.

• PasswordChangeView  (vue de changement de mot de passe)

• PasswordChangeDoneView  (vue de changement de mot de passe accompli)

Essayez par vous-même !

Une fois que vous aurez fini, ou si vous êtes bloqué sur quelque chose, vous pouvez voir l’implémentation correcte en regardant la solution sur GitHub.

Utilisation des vues basées sur des classes contre des vues basées sur des fonctions

Eh bien, on a couvert beaucoup de terrain ! N’oubliez pas qu’il y a trois approches principales pour implémenter des vues :

• Les vues basées sur des fonctions : la requête est gérée par une fonction, et les différents types de requêtes, comme  POST  et   GET, sont gérés par des instructions conditionnelles.

• Les vues basées sur les classes héritant dedjango.views.generic.View  : la requête est gérée par une classe, et les différents types de requêtes sont gérés par des méthodes séparées.

• Les vues génériques basées sur des classes : la requête est gérée par une vue générique basée sur une classe, qui vous permet d’éviter d’écrire la logique de la vue communément utilisée.

Bon, j’ai une mauvaise nouvelle : il n’y a pas de réponse absolue ! Tout dépend de votre préférence.

Le livre de Daniel et Audrey Feldroy, Two Scoops of Django 3.x (une excellente ressource en anglais pour les meilleures pratiques en Django), donne une bonne explication des écoles de pensée au sujet des vues. En voici un résumé :

Bien que le type de vue que l’on utilise dépende souvent d’une préférence personnelle, il y a généralement trois approches que les développeurs vont adopter :

1. Utiliser des vues génériques dès que et partout où c’est possible, ou sinon hériter de   django.views.generic.View. Cela réduit votre charge de travail, au prix néanmoins de la lisibilité.

2. Utiliser des vues basées sur les classes, mais en héritant uniquement de   django.views.generic.View  . Cette approche est utile si vous préférez la syntaxe des vues basées sur des classes, mais que vous voulez éviter les problèmes de lisibilité que l’on rencontre avec des vues génériques parfois obscures.

3. N’utiliser que des vues basées sur des fonctions, car elles sont souvent plus faciles à lire et à comprendre. Utiliser des vues basées sur la classe si l’on partage de gros morceaux de code entre les vues. Dans ce cas, on recommande de créer une vue de base basée sur la classe, puis de la spécialiser.

Une exception à ces approches, c’est que l’on utilise souvent des vues d’authentification génériques dans les projets qui emploient principalement une approche de vues basées sur des fonctions. En effet, elles permettent de vraiment gagner du temps au début d’un projet.

Dans le reste de ce cours, j’utiliserai des vues basées sur des fonctions pour construire le site. Néanmoins, vous êtes libre d’implémenter ces vues comme vues basées sur des classes ou même comme vues génériques si vous le préférez.

En résumé 

• Les vues basées sur des classes constituent une approche alternative aux vues basées sur des fonctions. Les deux sont tout à fait valables.

• Les vues génériques offrent de nombreux raccourcis qui permettent de minimiser le côté laborieux des tâches répétitives.

• Les vues d’authentification de Django sont des vues génériques utiles. Elles peuvent être utilisées pour éviter de gérer l’authentification bas niveau.

Maintenant que nous avons implémenté les vues d’authentification, construisons la fonctionnalité d’inscription du site.