Quand on fait:

class MaView(ListView):
    pass

MaView n’implémente pas dispatch, donc quand MaView.dispatch sera appelée, ListView.dispatch sera utilisé automatiquement.

Quand on fait:

class MaView(ListView):
    ...
    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        ...

MaView implémente dispatch. Du coup tout le code du parent (dont nous avons vu l’importance dans le commentaire précédent), n’est pas appelé, et la vue ne peut pas marcher. D’où le super(), qui permet d’appeler à la fin le dispatch du parent:

class MaView(ListView):
    ...
    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        return super(ProtectedView, self).dispatch(*args, **kwargs)

Dans le cas d’un mixin:

class MaVue(PermissionsRequiredMixin, ListView):
    required_permissions = (
        'dealer.create_cocaine',
        'dealer.delete_cocaine',
    )

MaVue n’implémente PAS dispatch. Donc quand on appelle MaVue.dispatch, c’est le PermissionsRequiredMixin.dispatch qui est appelé. Qui heureusement appelle ListView.dispatch ce qui permet à la vue de marcher.

    def dispatch(self, request, *args, **kwargs):
        # Try to dispatch to the right method; if a method doesn't exist,
        # defer to the error handler. Also defer to the error handler if the
        # request method isn't on the approved list.
        if request.method.lower() in self.http_method_names:
            handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
        else:
            handler = self.http_method_not_allowed
        self.request = request
        self.args = args
        self.kwargs = kwargs
        return handler(request, *args, **kwargs)

Le rôle de dispatch() est donc multiple:

- appeler la méthode post() ou get() (ou head() ou option(), etc. car tous les verbes HTTP sont disponibles) de la vue selon le type de requête;
- si le verbe HTTP n’est pas un verbe connu, appeler la méthode http_method_not_allowed();
- si le verbe HTTP fait parti des methodes interdites pour cette vue, appeler http_method_not_allowed();
- ajouter à l’instance courante de la vue les attributs request, args et kwargs.

On appelle donc TOUJOURS la méthode dispatch du parent, car toutes ces étapes sont nécessaires, pour toute les vues.

Typiquement, dans le cas d’une vue de formulaire, on aura toujours du GET (pour l’affichage du formulaire à vide) et du POST (pour l’envoie des données du formulaire), donc c’est toujours utile dans ce cas.

C’est d’ailleurs exactement ce que fait la vue générique ProcessFormView:

https://docs.djangoproject.com/en/1.4/ref/class-based-views/#processformview

Mais même dans le cas hypothétique d’une vue qui n’accepte que POST (ce qui est dommage, HEAD étant un verbe HTTP très utilisé par les navigateurs WEB pour la gestion du cache), on souhaite quand même garder dispatch()car elle a un rôle de sécurité: elle appelle http_method_not_allowed pour tous les autres verbes HTTP. Sans compter que sans self.request et self.kwargs, on ne peut pas faire grand chose dans une CBV.