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. On Thursday, November 8, 2012 4:29:54 PM UTC-7, Russell Keith-Magee wrote: > > > > On Thu, Nov 8, 2012 at 8:42 PM, Diederik van der Boor > <[email protected]<javascript:> > > wrote: > >> >> Op 7 nov. 2012, om 17:49 heeft Aaron Merriam het volgende geschreven: >> >> 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. >> >> >> I really like the idea of this implementation. I do like to see some >> examples associated with this feature, >> and I think that would be valuable for everyone :) >> >> I still think such init() or initial() feature would be beneficial for >> CBV's, >> and actually reduce complexity (cc Russell here) but the examples make >> the difference here :) >> >> For example, how would this be written without a init method? >> >> >> class PhotoListView(TabbedListView): >> """ >> Contents of an photo album; a list of photo's. >> """ >> model = Photo >> >> template_name = "photoalbum_album.html" >> permission_class = permissions.**PhotoAlbumViewPerm**ission >> >> def init(self): >> super(PhotoListView, self).init() # runs permission checks >> self.photoalbum = get_object_or_404(PhotoAlbum, >> pk=self.kwargs['pk']) # parent object that filters the list >> >> def get_queryset(self): >> return super(PhotoListView, self).get_queryset().in_album(**** >> self.photoalbum) >> >> def get_context_data(self, **kwargs): >> context = super(PhotoListView, self).get_context_data(****kwarg** >> s) >> context['photoalbum'] = self.photoalbum >> context['can_delete'] = self.is_authorized_for(**PhotoDe** >> leteView) >> return context >> >> >> Off course you can, but I'd like to initiate that challenge to get a good >> view of the complexity trade-offs here. >> >> > I'd like to offer an answer here, but it isn't clear to me at all what > this is trying to do (or rather, what ordering dependencies are assumed to > exist. > > For some reason, init() is apparently doing permission checks by default > -- but it isn't clear what causes those permission checks to be done; it > also isn't clear how you can do permission checks before you've actually > got an object to work with. > > As far as setting self.photoset -- that could be done in dispatch(), or in > get(), or possibly even in get_queryset(). > > In short, there isn't enough detail here for me to pass comment. > > Yours, > Russ Magee %-) > -- 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/-/lCqS_6cthaIJ. 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.
