Re: RFC: "universal" view decorators

On Jun 8, 2013, at 12:48 PM, Hanne Moa wrote: > On 3 June 2013 18:09, wrote: > # `DecoratorMixin` > > `DecoratorMixin` is a class factory that converts any view decorator into a > class-based view mixin. > > Using it is easy and intuitive: > >

Re: RFC: "universal" view decorators

On 3 June 2013 18:09, wrote: > # `DecoratorMixin` > > `DecoratorMixin` is a class factory that converts any view decorator into > a class-based view mixin. > > Using it is easy and intuitive: > > LoginRequiredMixin = DecoratorMixin(login_required) > Now this, this feels

Re: RFC: "universal" view decorators

Attempting to make decorators anticipate every usage is the wrong approach. In Django, the sole interface to a view is as a callable that accepts an `HttpRequest` and turns it into an `HttpResponse` or exception. Django the framework doesn't actually need to support class-based views--because

Re: RFC: "universal" view decorators

On Saturday, May 18, 2013 5:57:49 AM UTC-7, Marc Tamlyn wrote: > > I'm going to resurrect this old thread as I'd like to get it resolved in > some fashion. > > I used to be very in favour of the class decorators approach. I've been > using an implementation of `@class_view_decorator(func)` for

Re: RFC: "universal" view decorators

On May 18, 2013, at 8:57 AM, Marc Tamlyn wrote: > I'm going to resurrect this old thread as I'd like to get it resolved in some > fashion. > > I used to be very in favour of the class decorators approach. I've been using > an implementation of

Re: RFC: "universal" view decorators

Definitely +1 on this idea. It seems to me like the cleanest solution yet proposed insofar as it provides the desired new functionality while requiring very little change for current code. Cheers, AT On Wed, Oct 12, 2011 at 5:31 PM, Donald Stufft wrote: > Sorry for the

Re: RFC: "universal" view decorators

On Sep 21, 8:44 am, Donald Stufft wrote: > > The goal is to provide a Mixin for class based views, a decorator for class > based views, a decorator for methods, and a decorator for functions, all from > the same codebase. > > Currently I have the decorator for

Re: RFC: "universal" view decorators

I just got my wisdom teeth removed so i'm not exactly feeling the greatest, however I committed what I've done so far and pushed to my copy of django on github. The goal is to provide a Mixin for class based views, a decorator for class based views, a decorator for methods, and a decorator for

Re: RFC: "universal" view decorators

Hi all, Haven't seen a comment on this topic for a few days, so was wondering if a core dev can make a design decision yet. I have some spare time in the remainder of this week, so if the (universal) decorator- approach is chosen, I should be able to finish it shortly (the mixin- approach

Re: RFC: "universal" view decorators

On 16-09-11 18:08, Javier Guerra Giraldez wrote: I guess that when you know by heart exactly what does each one do, they become a pleasure to use. They *are* a pleasure to use. A colleague switched an app over to class based views last week and he got rid of 30% of the code. And it was more

Re: RFC: "universal" view decorators

The main reason I got into the implementation is because I think it's an important detail, decorating classes in my opinion is the right thing to do when what you are doing is something along the lines of registering the class, or doing some sort of validation and raising an exception etc.

Re: RFC: "universal" view decorators

James, Your case seems to rest on what is "natural" - both in terms of how to modify existing control structures and as a general goal that our resulting syntax must "feel natural." I submit that the way that will "feel natural" is to simply allow decoration of any view, be it a class or a

Re: RFC: "universal" view decorators

On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft wrote: > unittest.skip isn't a Mixin, it turns the class into an exception and > raises it. > > It doesn't *turn* a class into anything, it simply returns a function, instead of a new class, and the function raises SkipTest,

Re: RFC: "universal" view decorators

unittest.skip isn't a Mixin, it turns the class into an exception and raises it. django.test.utils.override_settings is a mixin and it's terrible, it dynamically creates a new subclass, and overrides 2 methods. It's magic and more complex then need be. On Friday, September 16, 2011 at 9:50

Re: RFC: "universal" view decorators

On Fri, Sep 16, 2011 at 9:47 PM, James Bennett wrote: > We have the following constraints: > > 1. Django supports class-based views. > > 2. Django supports function-based views (ultimately these are the same > thing, which is that Django supports anything as a 'view' so

Re: RFC: "universal" view decorators

We have the following constraints: 1. Django supports class-based views. 2. Django supports function-based views (ultimately these are the same thing, which is that Django supports anything as a 'view' so long as it's callable, accepts an HttpRequest as its first positional argument when being

Re: RFC: "universal" view decorators

Existing in python != pythonic. (not stating that class decorators aren't pythonic, but that argument is flawed) Just watched the video my thoughts regarding it, and this discussion. The Augment pattern is a terrible use case for class decorators when you are just overriding methods. It's

Re: RFC: "universal" view decorators

On Sep 16, 2011, at 6:19 PM, Donald Stufft wrote: Documentation is being worked on, and is orthogonal to the current discussion of how to handle things like requiring logins with the new CBVs. I just watched "Class Decorators: Radically Simple" by Jack Diederich, who wrote the class

Re: RFC: "universal" view decorators

Documentation is being worked on, and is orthogonal to the current discussion of how to handle things like requiring logins with the new CBVs. On Friday, September 16, 2011 at 12:08 PM, Javier Guerra Giraldez wrote: > On Fri, Sep 16, 2011 at 8:34 AM, Reinout van Rees

Re: RFC: "universal" view decorators

On Fri, Sep 16, 2011 at 8:34 AM, Reinout van Rees wrote: > Watch out, in general, with adding more and more mixins. > > I explained just the most basic template CBV to a colleague: there are just > two mixins and a base class there, but his eyes already started to glaze >

Re: RFC: "universal" view decorators

In response to Reinout: For the majority of people they won't have to care about what the LoginRequired Mixin is doing, they'll just add it to their class definition and that will be the end of it, the same as if they were decorating it. The major differences being now all the "things" that

Re: RFC: "universal" view decorators

On 15-09-11 23:27, Donald Stufft wrote: tl;dr; Using Mixins to add in functionality to a CBV makes way more sense then using a decorator which is essentially going to be doing the same thing as a mixing would, it just makes finding what is going on harder, makes customizing the decorator harder

Re: RFC: "universal" view decorators

On Thu, Sep 15, 2011 at 6:27 PM, Donald Stufft wrote: > Gonna add this in here as well as ticket #14512 > > I think using decorators to modify the way a CBV behaves is the wrong way > to go about it, my reasoning is: > > 1) Decorators on functions make sense, since the

Re: RFC: "universal" view decorators

On Sep 16, 2011, at 11:42 AM, Łukasz Rekucki wrote: On 16 September 2011 10:17, Roald de Vries wrote: On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote: I would like to also comment on the new approach in that ticket. Making a shallow copy of a class is *MAGIC* to me. It

Re: RFC: "universal" view decorators

I don't agree with most points because they are assuming functions are less fancy, less customizable, less clean, more complex, etc than classes and this is not true (but let's not start FP vs OOP holywar here, FP and OOP are friends in python). I like Jacob's proposal because there should be

Re: RFC: "universal" view decorators

On 16 September 2011 10:17, Roald de Vries wrote: > On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote: >> >> As the ticket creator I feel obligated to reply :) > > Me (as the poster of the latest patch) too :) Nice to meet you. > >> Thinking about it now, it does look kinda

Re: RFC: "universal" view decorators

> I think the syntax should be something like: > > from django.contrib.auth.decorators import login_required, > permission_required > > class ProtectedView(MyView): >    view_decorators = [login_required, permission_required('foo.can_do_bar')] > There was a similar proposal on this list before

Re: RFC: "universal" view decorators

On 09/16/2011 11:20 AM, Roald de Vries wrote: On Sep 16, 2011, at 10:08 AM, Jonathan Slenders wrote: class ProtectedView(MyView): login_required = True Where 'MyView' checks all the view's options during a dispatch. Never liked inheritance with multiple base classes... How would I create

Re: RFC: "universal" view decorators

On Sep 16, 2011, at 10:08 AM, Jonathan Slenders wrote: class ProtectedView(MyView): login_required = True Where 'MyView' checks all the view's options during a dispatch. Never liked inheritance with multiple base classes... How would I create my own 'decorators' in this approach? Cheers,

Re: RFC: "universal" view decorators

Hi, On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote: Hi, On 15 September 2011 22:44, Jacob Kaplan-Moss wrote: #14512 proposes a adding another view-decorator-factory for decorating class-based views, which would turn the above into::

Re: RFC: "universal" view decorators

I agree with Donald's reasoning. Decorators belong to functional programming, not to OO programming. Though, I still like to keep using functions for my own views and there are decorators appropriate. But if you go class based, you better use inheritance. However, instead of mix-ins, I'd rather

Re: RFC: "universal" view decorators

On 09/15/2011 11:27 PM, Donald Stufft wrote: tl;dr; Using Mixins to add in functionality to a CBV makes way more sense then using a decorator which is essentially going to be doing the same thing as a mixing would, it just makes finding what is going on harder, makes customizing the decorator

Re: RFC: "universal" view decorators

On 15 September 2011 23:27, Donald Stufft wrote: > Gonna add this in here as well as ticket #14512 > I think using decorators to modify the way a CBV behaves is the wrong way to > go about it, my reasoning is: > 1) Decorators on functions make sense, since the only way to

Re: RFC: "universal" view decorators

2011/9/16 Łukasz Rekucki : > Hi, >> I believe, however, I've figured out a different technique to make >> this work: don't try to detect bound versus unbound methods, but >> instead look for the HttpRequest object. It'll either be args[0] if >> the view's a function, or args[1]

Re: RFC: "universal" view decorators

Hi, On 15 September 2011 22:44, Jacob Kaplan-Moss wrote: > > #14512 proposes a adding another view-decorator-factory for decorating > class-based views, which would turn the above into:: > >    @class_view_decorator(login_required) >    class MyView(View): >        ... > >

Re: RFC: "universal" view decorators

Gonna add this in here as well as ticket #14512 I think using decorators to modify the way a CBV behaves is the wrong way to go about it, my reasoning is: 1) Decorators on functions make sense, since the only way to modify a function is to wrap it, so decorators provide a shortcut to do so.