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]. >>> > 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. >>> >>> -- >>> 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. >>> >>> >> -- >> 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. >> > > -- > 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. > -- 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.
