On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam <[email protected]>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 [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-developers?hl=en.
