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
> --
> 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 django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
self.request = requestself.args = argsself.kwargs = kwargs
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: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/3983252Cheers,
Jordan
--
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.
At first I wasn't sure about this hook, but after working with permissions in CBVs I can see how this would allow for much simpler code, especially when you're implementing a lot of subclassing. I tend to get carried away in writing mixins and base classes for my views, so yeah, I'm +1 on this too.
Cheers,
AT
-- Sent from my phone, please excuse any typos. --
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Um5fZBppDqMJ.
As it seems that there is no longer any real opposition to this ticket (if there is, now would be the time to speak up) I'll go ahead and prepare a patch against the current trunk and get it uploaded to trac and see where we get to from there.Hopefully I'll get a chance to take a look at this this week, I'll post a link to the trac ticket here once I've opened it.
I'm sorry if I came across that way, that wasn't my intention at all. Andre Terra who was the one to initially raise opposition has changed his stance on the functionality since he first posted, as per his email 4 days ago. Aside from him there is Tino de Bruijn who voiced opposition, although he seems to be the only other person in the history of the thread (not counting your post just now). There was also Michael van Tellingen, however I'm not 100% sure what his position on the topic is.
From my count there are 8 people in this thread in support of the functionality, and 2 people against it (1 at the time of my previous message).
In regards to your concerns, which mainly seem to be in regards to how many people would actually utilize this feature / are currently working around it I'm not sure how to address that. I suppose mixins are the solution for now then, however it does seem to me like something that anyone who is making extensive use of class based views will eventually come up against.
From my count there are 8 people in this thread in support of the functionality, and 2 people against it (1 at the time of my previous message).The bit you're possibly missing due to the way GMail handles some replied: this thread was a respawn of an older thread from 6 months ago. The google group has the full thread.
Of course, you might just be using your 5-person consensus to establish that it's worth going to the trouble of actually working up a patch, but it sounded like you were under the impression that your 5-person consensus was enough to end up with a patch in trunk, and I want to moderate your expectations.
In regards to your concerns, which mainly seem to be in regards to how many people would actually utilize this feature / are currently working around it I'm not sure how to address that. I suppose mixins are the solution for now then, however it does seem to me like something that anyone who is making extensive use of class based views will eventually come up against.I'm not saying that you don't have a use for this type of entry point. What I'm saying is that you're advocating making the basic entry sequence of class based views (and thus, the documentation and learning curve) more complex, all to service a use case that can be achieved with subclassing. And, in the limited subset of people that have *huge* subclassing overheads and find themselves writing that subclassing code over and over again, that subset can write a new base subclass or mixing that introduces the complexity.What I *don't* see is a generic, across the board need that warrants *every* user being forced to carry the overhead so that *some* users have a convenience that can be achieved by other means.
I wanted to post and modified version of a gist posted earlier in this thread.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.
Without setting request, args, and kwargs on on the view instance (which is done during the base dispatch view), anything in the view that assumes these values are present cannot run.Most of my views end up with functions which retrieve an object and then do some basic validation to ensure that a user has permissions, or that the object is valid in some fashion, or that some set of conditions is met prior to allowing any method call to happen.I have found that without this init method, the vast majority of my views end up re-writing dispatch which includes the super call. This is especially annoying when you have to compare some aspect of the requesting user with an object that must be looked up with something from args or kwargs. My view often already has this machinery built in, but it can't function without dispatch setting request, args, and kwargs, so to accomplish my check, I have to duplicate the lookup code in my dispatch method.I don't propose mine is the best solution, but I know that it is non-intrusive, simple, and covers my use cases well. It is also simple to accomplish any number of things since `init` merely needs to return a falsy value to allow the request to pass on through, raise an exception if that type of failure is desired, or return a response of it wants to hijack the view entirely.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group, send email to mailto:django-developers%2Bunsu...@googlegroups.com.
What I don't understand is why the need for an init() method isn't being challenged in the first place.Why on earth can't just just take the logic that you're putting in init(), and put it *in dispatch()*. The sequence of calls is *identical*, and since *args and **kwargs are locals, they don't need to be set anywhere. What's the problem with putting the init() logic in the dispatch() method in the way I described?
What is the problem with overriding dispatch()?When overriding dispatch(), get() or post() the flow is always:
def dispatch(self, request, *args, **kwargs):
# my code here.return super(…).dispatch(request, *args, **kwargs)The same also applies to get() and post().In other words, the last deriving class on top of the inheritance chain is always initializing first before it's base classes.It can't rely on a base class to do some initialization.With our permission check in the base class' dispatch() method, anything deriving from that effectivelycouldn't override dispatch() anymore because that would run before the permission check.How does the init method fix this?By doing a self.init() in the top-most dispatch() method, each class in the inheritance chain has a chance to fetch the objects it needs to have.That code can be written as:def init(self):super(..).init()# my code here.Now, the base class can initialize, then the deriving class.With a larger inheritance chain, this behavior becomes crucial.Each class can build upon what the other has prepared already.
Can you elaborate the nasty side effects you are thinking of? I can’t think of any that that the base views do to warrant your statement.From: Aaron MerriamSent: Friday, November 09, 2012 3:12 PMSubject: Re: Class based views: A standard hook for http-method-independent codeThat pattern has nasty side-effects. It can be used in some cases but it fails in most.
On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote:I’ve done the below in the past, the only issue with that is if you have side effects in parent’s dispatch you don’t want executed but you would also run that risk if you had an initialize() method work flow; in the end I find dispatch() is enough in my experience.def dispatch(self, request, *args, **kwargs):parent_dispatch_return = super(Class, self).dispatch(request, *args, **kwargs)...my code based on values based on the super call...return parent_dispatch_return
The git link seems to be broken. I'd love to see this bit of code everyone is raving about!
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.For more options, visit https://groups.google.com/groups/opt_out.