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: CSRF protection and cookies

> I had forgot about the Referer header check. It seems that it > would stop the subdomain-to-subdomain CSRF attacks as long as > the site is only using HTTPS,  wouldn't it? Yep. I think the balance there makes sense. It would be nice to figure out a good way to do optional checking for

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: Should I split ticket #16502 in three tickets or not?

Yes, there are tests for both #16502 and handling empty list of templates in third patch. So separating `select_template` issue is only necessary? On Friday, September 16, 2011 7:24:32 PM UTC+6, TiNo wrote: > > I think the get_model method serves well. As there are multiple ways to > define

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: Should I split ticket #16502 in three tickets or not?

I think the get_model method serves well. As there are multiple ways to define which model should be used (the self.model, self.queryset or self.form_class attributes) it justifies having a utility function for it. If you write tests for #16502 that pass with #16502 fixed with the get_model

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: Should I split ticket #16502 in three tickets or not?

I've already started on splitting patches so let me finish a work and separate tickets :) As I understand the problem, there should be patch without addition of `get_model` to resolve #16502 with tests, patch (and another ticket) which adds `get_model` with tests specially for `get_model` and

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: Should I split ticket #16502 in three tickets or not?

I agree. But the problem is this: CreateView has a default template: %app_name%/%model_name%_form.html , however, it should raise an error if no queryset or model is passed. The SingleObjectMixin-get_model.diff patch does this. It just needs tests. I would create a seperate ticket for handling an

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: CSRF protection and cookies

Paul McMillan writes: > In the meantime, if you use SSL on each of your subdomains, you get > strict checking of the Referer header for CSRF, which mitigates that > particular avenue of attack. Since you're using sessions and auth, you > should be using SSL, and so the

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