+1, this looks like a good change anyway and doesn't smell to me. On Fri, Nov 16, 2012 at 6:09 AM, Daniel Sokolowski <daniel.sokolow...@klinsight.com> wrote: > I like this approach. > > From: George Hickman > Sent: Thursday, November 15, 2012 7:27 AM > To: django-developers@googlegroups.com > Subject: Re: Class based views: A standard hook for http-method-independent > code > > I have a slightly different proposal, one where we can avoid the extra hook > but hopefully cover everyone's use cases too. > > https://github.com/ghickman/django/commit/85ac39a481074c25af1ed72a7a12e62ff5425e54 > > I've personally never liked the setting of args, kwargs & request from > within dispatch since it seems like it's feature creep of the dispatch > method. However I'm also in the same boat as many of the other posters here > in needing to do permissions related checks before dispatch is called. > > With my suggestion above you would be able to put your pre-dispatch code in > a subclasses overridden dispatch before calling super while also depending > on args, kwargs & request on self. > > On Thursday, November 15, 2012 4:18:34 AM UTC, Aaron Merriam wrote: >> >> If the super call changes any data then by the time you've run whatever >> code comes after the super call, the changes have already occured. >> >> >> If you wait to call super before running your own code, then request, >> args, and kwargs are not available on the request, so anything that depends >> on them being there (such as self.get_object()) will not work, so it must be >> re-implemented, >> Otherwise you have to set request, args, kwargs yourself which does not >> feel very DRY. >> >> For me, the entire reason I would like this change, is so that I can do >> something before dispatch that uses self.request/args/kwargs. Everything I >> want can be accomplished within dispatch, but not as cleanly, or as DRY as >> if this method hook existed. >> >> On Wednesday, November 14, 2012 6:49:06 AM UTC-7, Daniel Sokolowski wrote: >>> >>> Can you elaborate the nasty side effects you are thinking of? I can’t >>> think of any that that the base views do to warrant your statement. >>> >>> From: Aaron Merriam >>> Sent: Friday, November 09, 2012 3:12 PM >>> To: django-d...@googlegroups.com >>> Subject: Re: Class based views: A standard hook for >>> http-method-independent code >>> >>> That pattern has nasty side-effects. It can be used in some cases but it >>> fails in most. >>> >>> On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: >>>> >>>> I’ve done the below in the past, the only issue with that is if you have >>>> side effects in parent’s dispatch you don’t want executed but you would >>>> also >>>> run that risk if you had an initialize() method work flow; in the end I >>>> find >>>> dispatch() is enough in my experience. >>>> >>>> def dispatch(self, request, *args, **kwargs): >>>> parent_dispatch_return = super(Class, self).dispatch(request, *args, >>>> **kwargs) >>>> ...my code based on values based on the super call... >>>> return parent_dispatch_return >>>> >>>> From: Jordan Hagan >>>> Sent: Friday, November 09, 2012 12:37 AM >>>> To: django-d...@googlegroups.com >>>> Subject: Re: Class based views: A standard hook for >>>> http-method-independent code >>>> >>>> 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 >>>> <rus...@keith-magee.com> wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam <aaronm...@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-d...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> mailto:django-developers%2bunsubscr...@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-d...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> django-develop...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/django-developers?hl=en. >>>> >>>> Daniel Sokolowski >>>> http://webdesign.danols.com/ >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django developers" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/django-developers/-/41VjHYR1wmYJ. >>> To post to this group, send email to django-d...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-develop...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >>> Daniel Sokolowski >>> http://webdesign.danols.com/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/R-pHy86EH7IJ. > 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. > > Daniel Sokolowski > http://webdesign.danols.com/ > > > -- > 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.
