Re: Class based views: A standard hook for http-method-independent code

n Wednesday, November 14, 2012 6:49:06 AM UTC-7, Daniel Sokolowski >>> wrote: >>>> >>>> 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. >>>> >>

Re: Class based views: A standard hook for http-method-independent code

gt; *To:* django-d...@googlegroups.com > *Subject:* Re: Class based views: A standard hook for > http-method-independent code > > I have a slightly different proposal, one where we can avoid the extra > hook but hopefully cover everyone's use cases too. > > >

Re: Class based views: A standard hook for http-method-independent code

> >> > From: George Hickman >> > Sent: Thursday, November 15, 2012 7:27 AM >> > To: django-d...@googlegroups.com >> > Subject: Re: Class based views: A standard hook for >> http-method-independent >> > code >> > &g

Re: Class based views: A standard hook for http-method-independent code

ski > <daniel.s...@klinsight.com > wrote: > > I like this approach. > > > > From: George Hickman > > Sent: Thursday, November 15, 2012 7:27 AM > > To: django-d...@googlegroups.com > > Subject: Re: Class based views: A standard hook for > http-me

Re: Class based views: A standard hook for http-method-independent code

@klinsight.com> wrote: > > I like this approach. > > > > From: George Hickman > > Sent: Thursday, November 15, 2012 7:27 AM > > To: django-developers@googlegroups.com > > Subject: Re: Class based views: A standard hook for > http-method-independent > >

Re: Class based views: A standard hook for http-method-independent code

*Subject:* Re: Class based views: A standard hook for > http-method-independent code > > I have a slightly different proposal, one where we can avoid the extra > hook but hopefully cover everyone's use cases too. > > > https://github.com/ghickman/django/commit/85ac39a48

Re: Class based views: A standard hook for http-method-independent code

I like this approach. From: George Hickman Sent: Thursday, November 15, 2012 7:27 AM To: django-developers@googlegroups.com Subject: Re: Class based views: A standard hook for http-method-independent code I have a slightly different proposal, one where we can avoid the extra hook

Re: Class based views: A standard hook for http-method-independent code

think of any that that the base views do to warrant your statement. >> >> *From:* Aaron Merriam >> *Sent:* Friday, November 09, 2012 3:12 PM >> *To:* django-d...@googlegroups.com >> *Subject:* Re: Class based views: A standard hook for >> http-meth

Re: Class based views: A standard hook for http-method-independent code

inking of? I can’t > think of any that that the base views do to warrant your statement. > > *From:* Aaron Merriam > *Sent:* Friday, November 09, 2012 3:12 PM > *To:* django-d...@googlegroups.com > *Subject:* Re: Class based views: A standard hook for > h

Re: Class based views: A standard hook for http-method-independent code

worthwhile should voice so. Thanks From: Alex Ogier Sent: Wednesday, November 14, 2012 10:35 AM To: django-developers@googlegroups.com Subject: Re: Class based views: A standard hook for http-method-independent code For example, you miss Http404 and other error responses, which are implemented

Re: Class based views: A standard hook for http-method-independent code

*Sent:* Friday, November 09, 2012 3:12 PM > *To:* django-developers@googlegroups.com > *Subject:* Re: Class based views: A standard hook for > http-method-independent code > > That pattern has nasty side-effects. It can be used in some cases but it > fails in most. > > O

Re: Class based views: A standard hook for http-method-independent code

) ...my code based on values based on the super call... return parent_dispatch_return From: Jordan Hagan Sent: Friday, November 09, 2012 12:37 AM To: django-d...@googlegroups.com Subject: Re: Class based views: A standard hook for http-method-independent code Hey Russ

Re: Class based views: A standard hook for http-method-independent code

Op 9 nov. 2012, om 07:05 heeft Russell Keith-Magee het volgende geschreven: > 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()*.

Re: Class based views: A standard hook for http-method-independent code

> **kwargs) > ...my code based on values based on the super call... > return parent_dispatch_return > > *From:* Jordan Hagan > *Sent:* Friday, November 09, 2012 12:37 AM > *To:* django-d...@googlegroups.com > *Subject:* Re: Class based views: A standard hook fo

Re: Class based views: A standard hook for http-method-independent code

Subject: Re: Class based views: A standard hook for http-method-independent code Hey Russ, The main point of concern which I think you may be missing is that self.kwargs and self.args are set inside dispatch, so using other mixins that require self.kwargs and self.args to be set (most do

Re: Class based views: A standard hook for http-method-independent code

Not quite, other Mixins, take for example SingleObjectMixin require access to request, args, kwargs so to utilize the functionality of existing mixins in init(), we need to set self.request, self.args and self.kwargs

Re: Class based views: A standard hook for http-method-independent code

Ok… so let's get this straight: * init() needs to have access to request, args, kwargs * That means your implementation of dispatch() needs to set them. Sure. I'll pay that. If you assume that an init() method is required, then sure, you need to set up attributes to support it. What I don't

Re: Class based views: A standard hook for http-method-independent code

Hey Russ, The main point of concern which I think you may be missing is that self.kwargs and self.args are set inside dispatch, so using other mixins that require self.kwargs and self.args to be set (most do) will not work, without doing: def dispatch(self, request, *args, **kwargs):

Re: Class based views: A standard hook for http-method-independent code

On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam wrote: > 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

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code

On Thu, Nov 8, 2012 at 8:42 PM, Diederik van der Boor 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

Re: Class based views: A standard hook for http-method-independent code

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:

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code

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.() as usual.

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

> 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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

On Tue, Nov 6, 2012 at 7:48 AM, Jordan Hagan wrote: > 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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

On 6 November 2012 00:48, Jordan Hagan wrote: > > 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). There is also lots of other people that don't feel the need to join the thread

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

On Tue, Nov 6, 2012 at 2:20 AM, Jordan Hagan wrote: > 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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

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

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

Just wanted to put my +1 into this thread. I've been fighting for a clean way to implement permissions in class based views and the 'init' method would help my implementation be a lot more DRY. On Wednesday, October 31, 2012 12:42:33 PM UTC-6, Jordan Hagan wrote: > > Diedreik, > > Thanks for

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

Diedreik, Thanks for your comments - your solution seems similar to the one proposed by Meshy unless I'm missing something (https://gist.github.com/1957251). It is good to see multiple people coming up with the same solution to the issue independently though as that to me is an indication that

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

Marc and I have been using a mixin to override `dispatch()` with this functionality. He has an ongoing pull request on django-braceswith the code. I hope this can be useful to some of you. Meshy. On Wednesday, October 31, 2012 9:49:26 AM UTC,

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

Hi, Please allow me to add my €0.02. In a large project I've experienced a similar issue; and we solved it in a slightly different way. What we also noticed was: - overriding dispatch(), get() or post() wasn't good enough anymore. - the views need some initialization moment before their workflow

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code

> I don't really see what difference another function makes. > Sayhttps://gist.github.com/1957251is implemented, what makes: > > def prepare_view(self, request, *args, **kwargs): >     # the thing I want to do >     super(ClassName, self).prepare_view(request, *args, **kwargs) > > preferable

Re: Class based views: A standard hook for http-method-independent code

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:

Re: Class based views: A standard hook for http-method-independent code

That's not the case - get_context_data, get_queryset, are examples of hooks like this preprocess one, not places where more would be added. I'm not sure if there's a better analogy. Overriding the dispatch method would be the correct solution if you wanted to behave the same towards all methods,

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code

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 wrote:

Re: Class based views: A standard hook for http-method-independent code

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

Re: Class based views: A standard hook for http-method-independent code

I'd like to see something like this too: my suggestion is here: https://gist.github.com/1957251 This implementation also allows you to play with the request, args and kwargs before they are saved on the model. On Mar 1, 6:38 pm, Marc Tamlyn wrote: > Hi all, > > Apologies

Class based views: A standard hook for http-method-independent code

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