On 23 October 2010 08:08, Joachim Pileborg <[email protected]> wrote:
>
> On 19 Okt, 21:18, Łukasz Rekucki <[email protected]> wrote:
>> On 19 October 2010 19:06, Valentin Golev <[email protected]> wrote:> Hello,
>> > I was going to write something like LoginRequiredMixin, but I have no
>> > idea how to do this. I need to run my code before .dispatch(), but I
>> > also have to call the old dispatch, but since Mixin aren't inherited
>> > from View, I can't just override method and use super().
>>
>> This is option #4. You can just do:
>>
>> class LoginRequiredMixin(object):
>>
>> def dispatch(self, *args, **kwargs):
>> bound_dispatch = super(LoginRequired, self).dispatch
>> return login_required(bound_dispatch)(*args, **kwargs)
This discussion has moved to django-developers. It starts in [1] and
then continued in [2]. There is also a ticket #14512 for tracking this
issue[3]. All help is welcome :)
>
> This solution looks cleanest, and is easiest to implement. However
> there is
> a problem if two or more similar mixins are used: The order of the
> calls are
> dependant on the order the view inherits the mixins.
Yes it is. But I don't really see a problem with this. That's how
Python works. Wrapping the mixin construction to a class decorator
should make this a bit more obvious in what order the decorators will
be applied. With the code above, to wrap your view "MyView" with
a login_required you would need to do something like this:
class MyProtectedView(LoginRequiredMixin, MyView):
pass
> If you make a misstake
> in the inheritance-order, your mixin might not be called at all, which
> might not always be whats intended.
If all classes you inherit from play nicely (that means they call
super() in dispatch()), they your mixin will always be called. It
might be
called *earlier* then you expect, but not later or not at all.
>
> I am personally working on option #3, with a simple linked list of
> callables
> that calls each other until the original "get", "post", etc. is
> called.
See the links. There are some problems with decorators that leave
attributes (like csrf_protect) to consider. I will be more than happy
to work toghether.
[1]:
http://groups.google.com/group/django-developers/browse_frm/thread/f4bad32127776177
[2]:
http://groups.google.com/group/django-developers/browse_frm/thread/f36447f96277fe8c
[3]: http://code.djangoproject.com/ticket/14512
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
