Hey Russ,
The main point of concern which I think you may be missing is that
self.kwargs and self.args are set inside dispatch, so using other mixins
that require self.kwargs and self.args to be set (most do) will not work,
without doing:
def dispatch(self, request, *args, **kwargs):
self.args = args;
self.kwargs = kwargs
self.init()
return super(Class, self).dispatch(request, *args, **kwargs)
Which isn't very tidy, to me having self.args and self.kwargs be set twice
(once in my overridden dispatch method, and once in the original dispatch)
feels wrong. I can't give you a good reason for it, it just feels bad every
time I do it. The only way to work around this is to override dispatch
without calling the original, and essentially duplicate the original
dispatch method with an init call added in.
Cheers,
Jordan
On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <russ...@keith-magee.com
> wrote:
>
>
> On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam <aaronmerr...@gmail.com>wrote:
>
>> Without setting request, args, and kwargs on on the view instance (which
>> is done during the base dispatch view), anything in the view that assumes
>> these values are present cannot run.
>>
>> Most of my views end up with functions which retrieve an object and then
>> do some basic validation to ensure that a user has permissions, or that the
>> object is valid in some fashion, or that some set of conditions is met
>> prior to allowing any method call to happen.
>>
>> I have found that without this init method, the vast majority of my views
>> end up re-writing dispatch which includes the super call. This is
>> especially annoying when you have to compare some aspect of the requesting
>> user with an object that must be looked up with something from args or
>> kwargs. My view often already has this machinery built in, but it can't
>> function without dispatch setting request, args, and kwargs, so to
>> accomplish my check, I have to duplicate the lookup code in my dispatch
>> method.
>>
>> I don't propose mine is the best solution, but I know that it is
>> non-intrusive, simple, and covers my use cases well. It is also simple to
>> accomplish any number of things since `init` merely needs to return a falsy
>> value to allow the request to pass on through, raise an exception if that
>> type of failure is desired, or return a response of it wants to hijack the
>> view entirely.
>>
>>
> I'm starting to feel like I'm incredibly dense, because I still don't
> understand what your use case *is* - or, at least, why what your proposing
> provides any significant advantages over what you can do using basic Python
> inheritance techniques.
>
> Specifically, I still can't see why:
>
> class MyView(View):
> def dispatch(self, request, *args, **kwargs):
> init()
> return super(MyView, self).dispatch(request, *args, **kwargs)
>
> def init():
> # your init logic here
>
> is superior to the solution provided by using basic Python inheritance:
>
> class MyView(View):
> def dispatch(self, request, *args, **kwargs):
> # your init logic here
> return super(MyView, self).dispatch(request, *args, **kwargs)
>
> You have exactly the same workflow, and exactly the same order of
> operations. You don't need to document any special CBV-specific API --
> e.g., when/how init() will be invoked, and with what assumptions about the
> request environment can be made -- and you don't have to incur the overhead
> of a function call (ok - the overhead is tiny, but let's not pretend it's
> zero).
>
> So - can someone explain to me what the advantage is? Why is this init()
> method needed?
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
