I would really like to see something like Meshy's proposed solution implemented as this is an issue that I've run into a few times as well.
Although I can appreciate TiNo's argument of: > self.request = request > ... This creates a problem for methods that are going to be used in the overridden dispatch method and the dispatched method that need access to these attributes as they will need to be passed in as a parameter: in dispatch: self.some_method(request, *args, **kwargs) in dispatched: self.some_method(self.request, *self.args, **self.kwargs) which is just really messy. In addition to this methods from other generic view mixins cannot be used in the overridden dispatch method as they expect these class attributes to be available - 'get_object' on SingleObjectMixin is a good example of this as it requires self.kwargs to function: https://github.com/django/django/blob/master/django/views/generic/detail.py#L34 The only options available to us are monkey patching or code duplication, neither of which offer a good solution to this problem. Generic views are great for reducing boilerplate in code, and adding a hook in this case would do just that. Without this hook I'm forced to add code like the following to each of my projects as a workaround https://gist.github.com/3983252 Cheers, Jordan On Saturday, 17 March 2012 09:52:43 UTC+13, Mike Fogel wrote: > > I don't really see what difference another function makes. Sayhttps:// > gist.github.com/1957251is implemented, what makes: > > > > def prepare_view(self, request, *args, **kwargs): > > # the thing I want to do > > super(ClassName, self).prepare_view(request, *args, **kwargs) > > > > preferable over: > > > > def dispatch(self, request, *args, **kwargs): > > # the thing I want to do > > super(ClassName, self).dispatch(request, *args, **kwargs) > > > > ? > > https://gist.github.com/1957251 would allow: > > def prepare_view(self, request, *args, **kwargs): > super(ClassName, self).prepare_view(request, *args, **kwargs) > # the thing I want to do - can use self.request, self.args, > self.kwargs > > As things stand now, I don't know of a graceful manner to use > self.request in a http-method independent way. > > FWIW, I've ran into this restriction a number of times, including > today. If one of the core devs will nod approval on this, I'll open a > ticket and attach this gist to it. > > Cheers, > > Mike > > On Mar 4, 9:45 am, Tino de Bruijn <[email protected]> wrote: > > I don't really see what difference another function makes. Sayhttps:// > gist.github.com/1957251is implemented, what makes: > > > > def prepare_view(self, request, *args, **kwargs): > > # the thing I want to do > > super(ClassName, self).prepare_view(request, *args, **kwargs) > > > > preferable over: > > > > def dispatch(self, request, *args, **kwargs): > > # the thing I want to do > > super(ClassName, self).dispatch(request, *args, **kwargs) > > > > ? > > > > You'll still have a super call because otherwise you have to repeat the > > > > self.request = request > > self.args = args > > self.kwargs = kwargs > > > > part of prepare_view. > > > > What is wrong with overriding dispatch and calling super? (Or not, if > you > > don't want to progress in the view) > > > > Tino > > > > > > > > > > > > > > > > On Fri, Mar 2, 2012 at 18:15, Jonathan French <[email protected]> > wrote: > > > That's not the case - get_context_data, get_queryset, are examples of > > > hooks like this preprocess one, not places where more would be added. > I'm > > > not sure if there's a better analogy. > > > > > Overriding the dispatch method would be the correct solution if you > wanted > > > to behave the same towards all methods, but seems a bit heavy for > factoring > > > out validation or common code between methods where you still want > your > > > get/post/etc to be called (or not, as the case may be.) > > > > > - ojno > > > > > On 2 March 2012 15:22, Andre Terra <[email protected]> wrote: > > > > >> Then that would also be the case for many other methods in generic > > >> class-based views, like get_context_data, get_queryset, etc.. I hate > > >> boilerplate code as much as the next guy, but I'm not sure I follow > why > > >> this single method would get a special hook. Correct me if I'm wrong, > but > > >> special cases aren't special enough to break the rules. > > > > >> Cheers, > > >> AT > > > > >> On Fri, Mar 2, 2012 at 11:53 AM, Jonathan French < > [email protected]>wrote: > > > > >>> That's true, but I agree it seems a useful enough hook to make it a > > >>> hook, rather than needing to do it yourself like that. I would vote > for it > > >>> being called 'preprocess', to make it clear that it's both optional > and run > > >>> before the method-specific function. > > > > >>> - ojno > > > > >>> On 2 March 2012 13:40, Michael van Tellingen < > > >>> [email protected]> wrote: > > > > >>>> Hi, > > > > >>>> This should already be quite easy to implement, do something like: > > > > >>>> def dispatch(self, *args, **kwargs): > > >>>> # Some code > > >>>> return super(YourView, self).dispatch(*args, **kwargs) > > > > >>>> Regards, > > >>>> Michael > > > > >>>> On Fri, Mar 2, 2012 at 11:58, Charlie "meshy" Denton > > >>>> <[email protected]> wrote: > > >>>> > I would like to see something like this too. I my suggestion is > > >>>> > here:https://gist.github.com/1957251 > > > > >>>> > This method has two advantages: > > >>>> > 1. You can modify the request, args, and kwargs before they get > saved > > >>>> to the > > >>>> > view. > > >>>> > 2. You can execute code after request, args, and kwargs are saved > but > > >>>> before > > >>>> > the dispatch handler is called. > > >>>> > 3. You can save extra variables to self as required > > > > >>>> > I expect 2 is probably the most common use case. > > > > >>>> > Meshy. > > > > >>>> > On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote: > > > > >>>> >> Hi all, > > > > >>>> >> Apologies if this has been raised before. I've had a look around > and > > >>>> can't > > >>>> >> find a good way of doing this with the current code. > > > > >>>> >> I regularly have views which rely on some custom code which runs > some > > >>>> >> sanity checking on the request and is independent of method. As > an > > >>>> example, > > >>>> >> consider a view which creates an object related to a parent. > This is > > >>>> easily > > >>>> >> achievable by overriding the form_valid method of CreateView and > > >>>> excluding > > >>>> >> the foreign key from the form. However, the view should return a > 404 > > >>>> if the > > >>>> >> related object specified by the url does not exist. Written as a > non > > >>>> class > > >>>> >> based view, the natural flow is to try to load the parent object > > >>>> from the > > >>>> >> database, handle it as necessary, and then split paths depending > on > > >>>> whether > > >>>> >> we have a get or post. It is currently very difficult to emulate > this > > >>>> >> without duplication of some sort. > > > > >>>> >> My proposal is that we add a process_request (or similar name) > method > > >>>> >> which is called by the dispatch method immediately before the > method > > >>>> handler > > >>>> >> is called. (i.e. here). This would then allow pre-processing and > > >>>> sanity > > >>>> >> checking of the request object, using the args, kwargs and > request > > >>>> that have > > >>>> >> been saved on the class, before delegating off the the > respective > > >>>> views. The > > >>>> >> method should return None or an HttpResponse subclass. If it > returns > > >>>> >> something, then we return that directly from the dispatch > method. > > > > >>>> >> I can supply some code (my proposal is pretty simple I think) > but I > > >>>> >> thought I'd open it up for discussion first. > > > > >>>> >> Marc Tamlyn > > > > >>>> > -- > > >>>> > 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/-/z63TmT57twQJ. > > > > >>>> > To post to this group, send email to > > >>>> [email protected] <javascript:>. > > >>>> > To unsubscribe from this group, send email to > > >>>> > [email protected] <javascript:>. > > >>>> > 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 > > >>>> [email protected]<javascript:> > > >>>> . > > >>>> To unsubscribe from this group, send email to > > >>>> [email protected] <javascript:>. > > >>>> 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 > > >>> [email protected]<javascript:>. > > > >>> To unsubscribe from this group, send email to > > >>> [email protected] <javascript:>. > > >>> 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 > > >> [email protected]<javascript:>. > > > >> To unsubscribe from this group, send email to > > >> [email protected] <javascript:>. > > >> 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 > > > [email protected]<javascript:>. > > > > To unsubscribe from this group, send email to > > > [email protected] <javascript:>. > > > 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uYmm9IR6P7QJ. 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.
