I think the naming in rest framework is certainly nicer than init, purely from the being explicit point of view. Having a method with the same name as a dunder method seems like it would be a point of confusion for new comers too.
On Thursday, November 8, 2012 7:43:45 AM UTC, Mike Fogel wrote: > > I prefer django-rest-framework's flow through dispatch(). You can override > self.initial() to safely execute method-agnostic logic, but unlike your > example, it doesn't have to return a response object. The response object > is returned by the appropriate self.<method>() as usual. > > > https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/views.py#L339 > > > On Wednesday, November 7, 2012 8:49:04 AM UTC-8, Aaron Merriam wrote: >> >> I wanted to post and modified version of a gist posted earlier in this >> thread. >> >> https://gist.github.com/4032482 >> >> I originally implemented the original structure of having an `init` hook >> which was called between setting request, args, and kwargs, but i quickly >> found that I had a few situations where I needed to fully hijack the >> response rather than just checking a permission or throwing an exception. >> >> I'm curious what others think of this. >> >> On Thursday, March 1, 2012 11:38:08 AM UTC-7, 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/-/mhziYQW1TGwJ. 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.
