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 declare how this CBV behaves exist in one spot.If they don't need to customize the behavior of it, they don't have to, it will just work. If they do need to customize then the option is there to do so without having to copy/paste the code from Django into a utils.py and doing it themselves.
Basically a decorator adds the same amount of complexity into the stack, you just can't get at it because it's essentially a black box, so you can't tweak it. In response to Carl Meyer: Wrapping the view function like that is uglier (to me atleast) then just adding a mixin. There's no reason to do it like that and if that's the only option then I would prefer a decorator. The goal is to make it simple, easy and readable. To do so, In my opinion, we need to keep everything about a class, with the class, wrapping it in the urls.py, or down further in the views.py just gives yet another place to look to find out why a view is doing X. In response to Mikhail: Funcitions ARE less customizable then a nicely written class, tell me, with the current login_required how would you make it return a 403 instead of a redirect to login? Or how would you make it check that the user is_active as well as is_authorized? (The answer as far as I am aware is you would wrap them again, adding another layer of indirection). There is 0 reason why you can't support both @login_required and LoginRequired from the exact same code base, with just a little bit of a wrapper (most of which already exists and is required for the non class case anyways). In response to Łukasz: I disagree that preconditions are not modifying the functionality of a CBV. it's changing what can or cannot be returned from my view, it's changing how my view behaves, and from what I can tell, all of the current patches/implementations do it in a way that is basically what sub classing would do, just more opaquely and more magically. In regards to the declaring the decorators in a list: I'm generally -1 on that. It doesn't solve any of the problems that decorating has (well other then how to make them work with classes), and it is different from "normal" python conventions. On Fri, Sep 16, 2011 at 9:34 AM, Reinout van Rees <rein...@vanrees.org>wrote: > 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 and/or uglier, and goes >> against the way functionality is currently added to a CBV. >> > > 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 > over because I had to jump from class to class to class to explain how it > all hung together. > > Throw in a LoginRequiredMixin and SomeOtherMixin and you have the risk that > it turns into a big pile of un-debuggable code. Too many places to look. > Your mind's main working memory has a stack size between 6 and 8: you just > cannot juggle 3 base classes, 4 mixins and 2 method names at the same time. > > => A mixin isn't necessarily clearer than a decorator. > > > Reinout > > -- > Reinout van Rees http://reinout.vanrees.org/ > rein...@vanrees.org > http://www.nelen-schuurmans.**nl/<http://www.nelen-schuurmans.nl/> > "If you're not sure what to do, make something. -- Paul Graham" > > > -- > 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<django-developers@googlegroups.com> > . > To unsubscribe from this group, send email to > django-developers+unsubscribe@**googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at http://groups.google.com/** > group/django-developers?hl=en<http://groups.google.com/group/django-developers?hl=en> > . > > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
