Why does it use function arguments, and not self.kwargs, while, for
example, View.get() or post() methods use instance variables?
Is it going to change? I'm just curious. I understand that since this
is not the release, API is subject to change, so I'd like to know is
it going to change and how.
> Why does it use function arguments, and not self.kwargs, while, for > example, View.get() or post() methods use instance variables?
> Is it going to change? I'm just curious. I understand that since this > is not the release, API is subject to change, so I'd like to know is > it going to change and how.
Good catch! I've just made a change (r14292) to make get_object() more consistent with the rest of the class-based view API, dropping the (pk=None, slug=None, **kwargs) arguments in favor of using self.kwargs. I've also added formal API documentation for get_object(), which was omitted for some reason.
>> Why does it use function arguments, and not self.kwargs, while, for >> example, View.get() or post() methods use instance variables?
>> Is it going to change? I'm just curious. I understand that since this >> is not the release, API is subject to change, so I'd like to know is >> it going to change and how.
> Good catch! I've just made a change (r14292) to make get_object() more > consistent with the rest of the class-based view API, dropping the > (pk=None, slug=None, **kwargs) arguments in favor of using > self.kwargs. I've also added formal API documentation for > get_object(), which was omitted for some reason.
> Thanks for the feedback!
> Yours, > Russ Magee %-)
> -- > You received this message because you are subscribed to the Google Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev <m...@valyagolev.net> wrote: > Awesome, thank you!
> I've asked about @login_required and class based views in > django-users, and I'd like to ask here: are something like > LoginRequiredMixin's planned?
No, nothing like that is planned. This is a situation were decorators will be a better match in the general case, because login redirection can usually be transparently wrapped around a view.
You should be able to use decorators on class based views in the same way that you use them on normal function views.
<russ...@keith-magee.com> wrote: > On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev <m...@valyagolev.net> wrote: >> Awesome, thank you!
>> I've asked about @login_required and class based views in >> django-users, and I'd like to ask here: are something like >> LoginRequiredMixin's planned?
> No, nothing like that is planned. This is a situation were decorators > will be a better match in the general case, because login redirection > can usually be transparently wrapped around a view.
> You should be able to use decorators on class based views in the same > way that you use them on normal function views.
> Yours, > Russ Magee %-)
> -- > You received this message because you are subscribed to the Google Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> On Wed, Oct 20, 2010 at 2:59 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev <m...@valyagolev.net> wrote: >>> Awesome, thank you!
>>> I've asked about @login_required and class based views in >>> django-users, and I'd like to ask here: are something like >>> LoginRequiredMixin's planned?
>> No, nothing like that is planned. This is a situation were decorators >> will be a better match in the general case, because login redirection >> can usually be transparently wrapped around a view.
>> You should be able to use decorators on class based views in the same >> way that you use them on normal function views.
>> Yours, >> Russ Magee %-)
>> -- >> You received this message because you are subscribed to the Google Groups "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Wed, Oct 20, 2010 at 7:05 PM, Valentin Golev <m...@valyagolev.net> wrote: > As far as I know, I can just say:
> @login_required > class MyView(View): > # ...
> since it will wrap __init__
> I need either to create a decorator for decorators: > @on_dispatch(login_required) > class MyView(View):
> or decorate result of MyView().as_view().
> Maybe I'm wrong. I think it will be great to add something about it to > docs, since decorators is extremely wide-used feature.
As I've commented on the django-users thread, Django already provides method_decorator(), which provides a way to decorate the dispatch function (or any individual get/post etc HTTP method) on a class-based view.
The other simple way to decorate a view is to decorate the result of the as_view() call in the URL pattern -- i.e., instead of deploying:
MyView.as_view()
deploy:
login_required(MyView.as_view())
A class decorator (and/or a wrapper function for turning decorators into class decorators) is also an interesting idea. However, unlike method_decorator(), a class_decorator() would need to be view-specific, since it needs to modify the class it wraps in a specific way, rather than the completely generic approach that method_decorator() can take.
Regardless, your point about documenting these approaches is well taken. It isn't immediately obvious how decoration should work in a class-based world. If you open a ticket for this, that will help make sure that this idea isn't forgotten.
I think class decorator for views only is a great idea, because it will be:
a) just like with old view functions decorators b) does not require any method overrides/imports into urls.py/explicit transformations in views.py
I'd like Django to have a decorator for turning old decorators into decorators for class based views. I've hardly seen @login_required and lots of other common decorators not used in the view context, so why avoid being attached to Django views interface, since we already made up our minds about having such an interface.
So I think, both tickets - for docs and for "@on_dispatch()" decorators - are worth it.
-- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru
<russ...@keith-magee.com> wrote: > On Wed, Oct 20, 2010 at 7:05 PM, Valentin Golev <m...@valyagolev.net> wrote: >> As far as I know, I can just say:
>> @login_required >> class MyView(View): >> # ...
>> since it will wrap __init__
>> I need either to create a decorator for decorators: >> @on_dispatch(login_required) >> class MyView(View):
>> or decorate result of MyView().as_view().
>> Maybe I'm wrong. I think it will be great to add something about it to >> docs, since decorators is extremely wide-used feature.
> As I've commented on the django-users thread, Django already provides > method_decorator(), which provides a way to decorate the dispatch > function (or any individual get/post etc HTTP method) on a class-based > view.
> The other simple way to decorate a view is to decorate the result of > the as_view() call in the URL pattern -- i.e., instead of deploying:
> MyView.as_view()
> deploy:
> login_required(MyView.as_view())
> A class decorator (and/or a wrapper function for turning decorators > into class decorators) is also an interesting idea. However, unlike > method_decorator(), a class_decorator() would need to be > view-specific, since it needs to modify the class it wraps in a > specific way, rather than the completely generic approach that > method_decorator() can take.
> Regardless, your point about documenting these approaches is well > taken. It isn't immediately obvious how decoration should work in a > class-based world. If you open a ticket for this, that will help make > sure that this idea isn't forgotten.
> Yours, > Russ Magee %-)
> -- > You received this message because you are subscribed to the Google Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > A class decorator (and/or a wrapper function for turning decorators > into class decorators) is also an interesting idea.
An argument against this is "one way to do it". If I look at a class and want to know what decorators are applied, if would be nice if there was only one place to look. I guess that that one place could be the class rather than the 'dispatch' method, if we encourage that practice, but that pattern might be hard to encourage since class-decoration is less obvious (and certainly much less well established in the Django code base) than method decoration.
Luke
-- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard)
On 20 October 2010 15:59, Luke Plant <L.Plant...@cantab.net> wrote:
> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea.
> An argument against this is "one way to do it". If I look at a class > and want to know what decorators are applied, if would be nice if there > was only one place to look. I guess that that one place could be the > class rather than the 'dispatch' method, if we encourage that practice, > but that pattern might be hard to encourage since class-decoration is > less obvious (and certainly much less well established in the Django > code base) than method decoration.
OTOH, it'a annoying to have to write an dispatch() method with a super inside (which effectively does nothing), just to apply a decorator.
Well, since we are already using class Mixins for extending View functionality, we can try to turn decorators into mixins. Having two ways to add some functionality to class (decorators and mixins) can be somewhat uncomfortable.
I had some doubts if mixins can act as a "wrappers" to defined functions, but, as I was told, these doubts were based on my poor understanding of how "super()" and mixins work.
I totally agree with Łukasz about annoyance of decorating a dispatch() function.
-- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru
On Wed, Oct 20, 2010 at 5:59 PM, Luke Plant <L.Plant...@cantab.net> wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea.
> An argument against this is "one way to do it". If I look at a class > and want to know what decorators are applied, if would be nice if there > was only one place to look. I guess that that one place could be the > class rather than the 'dispatch' method, if we encourage that practice, > but that pattern might be hard to encourage since class-decoration is > less obvious (and certainly much less well established in the Django > code base) than method decoration.
> Luke
> -- > If you can't answer a man's arguments, all is not lost; you can > still call him vile names. (Elbert Hubbard)
> -- > You received this message because you are subscribed to the Google Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant <L.Plant...@cantab.net> wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea.
> An argument against this is "one way to do it". If I look at a class > and want to know what decorators are applied, if would be nice if there > was only one place to look. I guess that that one place could be the > class rather than the 'dispatch' method, if we encourage that practice, > but that pattern might be hard to encourage since class-decoration is > less obvious (and certainly much less well established in the Django > code base) than method decoration.
I'm not sure that argument holds up. Right now, we already have 2 ways to do it - you can decorate the view function at time of definition, and you can decorate when it is included in the URL pattern.
The class-based view case is also complicated by the common usage pattern. Consider a prototypical view:
You don't have to define dispatch or as_view -- the two places that can be decorated to provide class-wide behavior. You could decorate both get *and* post -- which may be a good approach in some cases (say you want all GETs to be allowed, but POSTs to be login protected) -- but it's an unusual duplication to require for the common case. You could also decorate the MyView.as_view() line in the URL pattern, but that doesn't enforce the decorator for every use.
There's no simple direct analog of the "make sure every access to this view is decorated". To me, a class-view-decorator seems like a way to express the existing use case.
> On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant <L.Plant...@cantab.net> wrote: >> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>>> A class decorator (and/or a wrapper function for turning decorators >>> into class decorators) is also an interesting idea.
>> An argument against this is "one way to do it". If I look at a class >> and want to know what decorators are applied, if would be nice if there >> was only one place to look. I guess that that one place could be the >> class rather than the 'dispatch' method, if we encourage that practice, >> but that pattern might be hard to encourage since class-decoration is >> less obvious (and certainly much less well established in the Django >> code base) than method decoration.
> I'm not sure that argument holds up. Right now, we already have 2 ways > to do it - you can decorate the view function at time of definition, > and you can decorate when it is included in the URL pattern.
> The class-based view case is also complicated by the common usage > pattern. Consider a prototypical view:
> You don't have to define dispatch or as_view -- the two places that > can be decorated to provide class-wide behavior. You could decorate > both get *and* post -- which may be a good approach in some cases (say > you want all GETs to be allowed, but POSTs to be login protected) -- > but it's an unusual duplication to require for the common case. You > could also decorate the MyView.as_view() line in the URL pattern, but > that doesn't enforce the decorator for every use.
> There's no simple direct analog of the "make sure every access to this > view is decorated". To me, a class-view-decorator seems like a way to > express the existing use case.
> Yours, > Russ Magee %-)
> -- > You received this message because you are subscribed to the Google Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > OTOH, it's annoying to have to write an dispatch() method with a super > inside (which effectively does nothing), just to apply a decorator.
That's a good point I hadn't thought of, as are Russell's other points.
Just to put it on the table, another option we thought of at one point was to have a 'decorators' attribute on the class, which is a list of decorators that is applied by the as_view() method. It would in theory allow you to add decorators to either end of the set of decorators that are applied, something like this:
It gets a bit trickier with multiple inheritance. I don't know if that would be too much of a big deal - I would imagine that most of the mixin classes would not be providing decorators. But then my imagination is probably limited.
Luke
-- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard)
On Thu, Oct 21, 2010 at 1:42 AM, Luke Plant <L.Plant...@cantab.net> wrote: > On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote:
>> OTOH, it's annoying to have to write an dispatch() method with a super >> inside (which effectively does nothing), just to apply a decorator.
> That's a good point I hadn't thought of, as are Russell's other points.
> Just to put it on the table, another option we thought of at one point > was to have a 'decorators' attribute on the class, which is a list of > decorators that is applied by the as_view() method. It would in theory > allow you to add decorators to either end of the set of decorators that > are applied, something like this:
> It gets a bit trickier with multiple inheritance. I don't know if that > would be too much of a big deal - I would imagine that most of the mixin > classes would not be providing decorators. But then my imagination is > probably limited.
Meh - this seems like reinventing a syntactic wheel to me. Python 2.6 has class decorators. They work in a predictable way, with predictable MRO combination rules. Trying to invent a new class-attribute syntax for class decoration seems like asking for trouble.
