Firstly, please excuse my double post: I didn't realise posts are vetted, so I thought it had been lost.
The very significant advantage of this being a hook (instead of overriding dispatch) is that it allows you to call methods that require dispatch to have already set variables (eg: self.kwargs) on the class before the handler (eg: get()) is called. Normally I have no problem overriding dispatch, but this has come up a couple of times for me, and overriding dispatch in this way has felt ugly. On Thursday, 1 March 2012 18:38:08 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<https://github.com/django/django/blob/master/django/views/generic/base.py#L68>). > > 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/-/imEZWRGm8ygJ. 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.
