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 <javascript:> > *Sent:* Friday, November 09, 2012 3:12 PM > *To:* django-d...@googlegroups.com <javascript:> > *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<javascript:> > . > To unsubscribe from this group, send email to > django-develop...@googlegroups.com <javascript:>. > 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/-/SI6gpstaNXYJ. 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.
