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.
