2016-04-15 11 views
2

ich staff_member_required Mixins umzusetzen versuchen:Django Mixins für klassenbasierte-generic Ansichten

Hier sind die beiden Möglichkeiten, wie ich auch gefunden, wie dies zu tun:

Erstens:

class StaffRequiredMixin(object): 
    @method_decorator(login_required) 
    def dispatch(self, request, *args, **kwargs): 
     if not request.user.is_staff: 
      messages.error(
       request, 
       'You do not have the permission required to perform the ' 
       'requested operation.') 
      return redirect(settings.LOGIN_URL) 
     return super(StaffRequiredMixin, self).dispatch(request, 
      *args, **kwargs) 

Zweitens:

class StaffRequiredMixin(object): 
    @classmethod 
    def as_view(self, *args, **kwargs): 
     view = super(StaffRequiredMixin, self).as_view(*args, **kwargs) 
     return staff_member_required(view) 

    @method_decorator(login_required) 
    def dispatch(self, request, *args, **kwargs): 
     if not request.user.is_staff: 
      messages.error(
       request, 
       'You do not have the permission required to perform the ' 
       'requested operation.') 
      return redirect(settings.LOGIN_URL) 
     return super(StaffRequiredMixin, self).dispatch(request, 
      *args, **kwargs) 

Was will ich wissen, ist:

  1. Warum überschreibt die zweite Methode die as_view() Methode und umhüllt sie mit staff_member_required?

  2. Erhalten wir dadurch irgendwelche "zusätzlichen" Vorteile?

Ich bin neu bei diesen Mixins. Bitte helfen Sie.

Antwort

3

TL; DR: sie sind in der Nähe der gleichen, der Unterschied ist in Überprüfung is_active sowie is_staff und der Fehler messages. Sie benötigen wahrscheinlich beide nicht, da die as_view Überschreibung die Notwendigkeit für die dispatch Überschreibung sowieso negiert.

Dies sind wirklich nur zwei Möglichkeiten, zu schließen auf die gleiche Sache.

Dieser Code:

class StaffRequiredMixin(object): 
    @classmethod 
    def as_view(self, *args, **kwargs): 
     view = super(StaffRequiredMixin, self).as_view(*args, **kwargs) 
     return staff_member_required(view) 

... könnte tatsächlich allein verwendet werden, um die staff_member_required decorator zu implementieren. In diesem Fall wird die Funktion staff_member_required in der Funktion as_view() der Sicht aufgerufen (d. H. Von as_view() in Ihrem URLConf).

Dieser Code:

class StaffRequiredMixin(object): 
    @method_decorator(login_required) 
    def dispatch(self, request, *args, **kwargs): 
     if not request.user.is_staff: 
      messages.error(
       request, 
       'You do not have the permission required to perform the ' 
       'requested operation.') 
      return redirect(settings.LOGIN_URL) 
     return super(StaffRequiredMixin, self).dispatch(request, 
      *args, **kwargs) 

... filtert Benutzer in der dispatch Methode. Sie können in der Django Codebase sehen, dass as_view actually calls dispatch. Das heißt, wenn Sie beide zusammen verwenden, werden Sie den Code if not request.user.is_staff in der dispatch Methode tatsächlich nie auslösen, da jeder Benutzer, der nicht besteht, in der as_view Methode herausgefiltert worden wäre.

Der zweite Unterschied ist, dass staff_member_required ist etwas anders als der erste Code tut. Wenn Sie check out the code, werden Sie feststellen, dass staff_member_required auch überprüft, ob der Benutzer is_active Flag übergibt (nicht nur is_staff wie in Ihrem dispatch Dekorateur). Es übergibt auch nicht die wie in Ihrem Code.