Re: RFC: "universal" view decorators

[Donald Stufft]

 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.  

django.test.utils.override_settings when decorating a class is nearly 
functionally equivalent to adding a mixin, it takes the base class, and adds in 
2 methods. It's not actually a mixing, but I meant it's nearly equivalent to a 
mixin (in the TestCase case). I don't think class decorators are the right way 
to do this sort of pseudo mixin in a very opaque way.  

That being said…

Is there a problem with turning the current decorators into mixins, and support 
both decorating the class, and mixing in from the same code base? It's somewhat 
unpythonic in the 2 ways to do it camp, but it'd all be done with 1 code base, 
and would satisfy both camps I believe?  


On Friday, September 16, 2011 at 10:32 PM, Alex Gaynor wrote:

>  
>  
> On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft  (mailto:donald.stu...@gmail.com)> 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, the point wasn't 
> the implementation detail, but rather the syntax and pattern at work.  
>  
> > 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.
> >  
>  
>  
> a) it's not a mixin
> b) yes, it creates subclasses, because the alternative is mutating the 
> original class, which isn't how people generally expect decorators to work, 
> we expect them to be syntactic sugar for:
>  
> A = wrap(*args)(A)
>  
> such that we can also do
>  
> B = wrap(*args)(A)
>  
> and have two classes (or functions).
>  
> c) I'm not sure how it's magic, but certainly if it's too complex we'd take 
> patches to simplify the implementation.  
>  
> >  
> > On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote:
> >  
> >  
> >  
> > >  
> > >  
> > > On Fri, Sep 16, 2011 at 9:47 PM, James Bennett  > > (mailto:ubernost...@gmail.com)> 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 long as
> > > >  it's callable, accepts an HttpRequest as its first positional argument
> > > >  when being called and either returns an HttpResponse or raises an
> > > >  exception).
> > > >  
> > > >  3. The natural way to add processing in/around a class is subclassing
> > > >  and either overriding or mixing in.
> > > >  
> > > >  4. The natural way to add processing in/around around a function is 
> > > > decorating.
> > > >  
> > > >  Any solution to this needs to address those constraints, and allow
> > > >  code to look and feel natural.
> > > >  
> > > >  Based on that, some arrangement which allows the same basic logic to
> > > >  exist in a "mixin" (I dislike that word) for classes and a decorator
> > > >  for functions seems most appropriate, even if it does mean having two
> > > >  ways to do things -- that's a distinction I think we can live with, as
> > > >  people will appreciate that it doesn't result in strange-looking code.
> > > >  
> > > >  
> > > >  --
> > > >  "Bureaucrat Conrad, you are technically correct -- the best kind of 
> > > > correct."
> > > >  
> > > >  --
> > > >  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 
> > > > (mailto:django-developers@googlegroups.com).
> > > >  To unsubscribe from this group, send email to 
> > > > django-developers+unsubscr...@googlegroups.com 
> > > > (mailto:django-developers%2bunsubscr...@googlegroups.com).
> > > >  For more options, visit this group at 
> > > > http://groups.google.com/group/django-developers?hl=en.
> > > >  
> > >  
> > > I agree with all your points, except #3, I think it's an over 
> > > simplification. There's another way to change a class: class decorators. 
> > > And there's ample precedent for their use in such a manner, unittest's 
> > > skip decorators, our own decorators for swapping settings during testing, 
> > > etc.
> > >  
> > > Alex
> > >  
> > > --  
> > > "I disapprove of what you say, but I will defend to the death your right 
> > > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > "The people's good is the highest law." -- Cicero
> > >  
> > >  --  
> > >  You received this message because you are subscribed to the Google 
> > > Groups 

Re: RFC: "universal" view decorators

[Justin Holmes]

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 function, with the
decorator whose name describes precisely the functional modification.
This is simple to read, easy to remember, and, frankly, DRY.


On Fri, Sep 16, 2011 at 7:27 PM, Donald Stufft  wrote:
> 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 PM, Alex Gaynor wrote:
>
> 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 long as
> it's callable, accepts an HttpRequest as its first positional argument
> when being called and either returns an HttpResponse or raises an
> exception).
>
> 3. The natural way to add processing in/around a class is subclassing
> and either overriding or mixing in.
>
> 4. The natural way to add processing in/around around a function is
> decorating.
>
> Any solution to this needs to address those constraints, and allow
> code to look and feel natural.
>
> Based on that, some arrangement which allows the same basic logic to
> exist in a "mixin" (I dislike that word) for classes and a decorator
> for functions seems most appropriate, even if it does mean having two
> ways to do things -- that's a distinction I think we can live with, as
> people will appreciate that it doesn't result in strange-looking code.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> 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.
>
>
> I agree with all your points, except #3, I think it's an over
> simplification.  There's another way to change a class: class decorators.
>  And there's ample precedent for their use in such a manner, unittest's skip
> decorators, our own decorators for swapping settings during testing, etc.
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
> --
> 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.
>
> --
> 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.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

-- 
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.

Re: RFC: "universal" view decorators

[Alex Gaynor]

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, the point wasn't
the implementation detail, but rather the syntax and pattern at work.


> 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.
>

a) it's not a mixin
b) yes, it creates subclasses, because the alternative is mutating the
original class, which isn't how people generally expect decorators to work,
we expect them to be syntactic sugar for:

A = wrap(*args)(A)

such that we can also do

B = wrap(*args)(A)

and have two classes (or functions).

c) I'm not sure how it's magic, but certainly if it's too complex we'd take
patches to simplify the implementation.


>  On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote:
>
>
>
> 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 long as
> it's callable, accepts an HttpRequest as its first positional argument
> when being called and either returns an HttpResponse or raises an
> exception).
>
> 3. The natural way to add processing in/around a class is subclassing
> and either overriding or mixing in.
>
> 4. The natural way to add processing in/around around a function is
> decorating.
>
> Any solution to this needs to address those constraints, and allow
> code to look and feel natural.
>
> Based on that, some arrangement which allows the same basic logic to
> exist in a "mixin" (I dislike that word) for classes and a decorator
> for functions seems most appropriate, even if it does mean having two
> ways to do things -- that's a distinction I think we can live with, as
> people will appreciate that it doesn't result in strange-looking code.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> 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.
>
>
> I agree with all your points, except #3, I think it's an over
> simplification.  There's another way to change a class: class decorators.
>  And there's ample precedent for their use in such a manner, unittest's skip
> decorators, our own decorators for swapping settings during testing, etc.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>  --
> 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.
>
>
>  --
> 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.
>

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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.

Re: RFC: "universal" view decorators

[Donald Stufft]

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 PM, Alex Gaynor wrote:

> 
> 
> On Fri, Sep 16, 2011 at 9:47 PM, James Bennett  (mailto:ubernost...@gmail.com)> 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 long as
> >  it's callable, accepts an HttpRequest as its first positional argument
> >  when being called and either returns an HttpResponse or raises an
> >  exception).
> > 
> >  3. The natural way to add processing in/around a class is subclassing
> >  and either overriding or mixing in.
> > 
> >  4. The natural way to add processing in/around around a function is 
> > decorating.
> > 
> >  Any solution to this needs to address those constraints, and allow
> >  code to look and feel natural.
> > 
> >  Based on that, some arrangement which allows the same basic logic to
> >  exist in a "mixin" (I dislike that word) for classes and a decorator
> >  for functions seems most appropriate, even if it does mean having two
> >  ways to do things -- that's a distinction I think we can live with, as
> >  people will appreciate that it doesn't result in strange-looking code.
> > 
> > 
> >  --
> >  "Bureaucrat Conrad, you are technically correct -- the best kind of 
> > correct."
> > 
> >  --
> >  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 
> > (mailto:django-developers@googlegroups.com).
> >  To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com 
> > (mailto:django-developers%2bunsubscr...@googlegroups.com).
> >  For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en.
> > 
> 
> I agree with all your points, except #3, I think it's an over simplification. 
> There's another way to change a class: class decorators. And there's ample 
> precedent for their use in such a manner, unittest's skip decorators, our own 
> decorators for swapping settings during testing, etc.
> 
> Alex
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to 
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> 
>  -- 
>  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 
> (mailto:django-developers@googlegroups.com).
>  To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
>  For more options, visit this group at 
> 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.

Re: RFC: "universal" view decorators

[Alex Gaynor]

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 long as
> it's callable, accepts an HttpRequest as its first positional argument
> when being called and either returns an HttpResponse or raises an
> exception).
>
> 3. The natural way to add processing in/around a class is subclassing
> and either overriding or mixing in.
>
> 4. The natural way to add processing in/around around a function is
> decorating.
>
> Any solution to this needs to address those constraints, and allow
> code to look and feel natural.
>
> Based on that, some arrangement which allows the same basic logic to
> exist in a "mixin" (I dislike that word) for classes and a decorator
> for functions seems most appropriate, even if it does mean having two
> ways to do things -- that's a distinction I think we can live with, as
> people will appreciate that it doesn't result in strange-looking code.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> 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.
>
>
I agree with all your points, except #3, I think it's an over
simplification.  There's another way to change a class: class decorators.
 And there's ample precedent for their use in such a manner, unittest's skip
decorators, our own decorators for swapping settings during testing, etc.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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.

Re: RFC: "universal" view decorators

[James Bennett]

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 called and either returns an HttpResponse or raises an
exception).

3. The natural way to add processing in/around a class is subclassing
and either overriding or mixing in.

4. The natural way to add processing in/around around a function is decorating.

Any solution to this needs to address those constraints, and allow
code to look and feel natural.

Based on that, some arrangement which allows the same basic logic to
exist in a "mixin" (I dislike that word) for classes and a decorator
for functions seems most appropriate, even if it does mean having two
ways to do things -- that's a distinction I think we can live with, as
people will appreciate that it doesn't result in strange-looking code.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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.

Re: CSRF protection and cookies

[Paul McMillan]

> 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 non-HTTPS, but really,
everyone should be using HTTPS.

-Paul

-- 
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.

Re: RFC: "universal" view decorators

[Donald Stufft]

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 nothing more then Mixins with a different syntax, 
for no reason that I can determine other then someone not liking the way 
declaring a mixin looks, functionally you are still mixing in. What benefit do 
you get from hiding the fact you are really just doing a Mixin? With the code 
Jacob posted there is… 16? (My math might be wrong) different permutations of 
code flow just to support universal decorators.  

The order would matter in the sense that any mixins would have to come before 
the base view class, so:

class ProtectedView(LoginRequired, View)

is valid but

class ProtectedView(View, LoginRequired)

is not.

But this is just python, there's nothing magical about object inheritance and 
in python object inheritance is left to right.

Additionally, as I just thought, there is a way to satisfy both camps. The 
support code I proposed to allow @login_required with Mixins to still work with 
function based views could include the universal decorator approach that Jacob 
included.

That would be a change so that the actual "is this a user, are they logged in 
etc" logic would live in a class that could be mixed in, then the support code 
for functions would use that class and wrap the test portions around the 
function view, and then the universal decorator code could just do the Augment 
pattern.

All camps == Happy? People who prefer mixins can mixin, people who prefer 
@decorators can decorate, everything is supported from one code base.  


On Friday, September 16, 2011 at 1:45 PM, Roald de Vries wrote:

> 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 decorators PEP, and I think it's very useful to  
> watch (25 min.) for this discussion. According to him it is good  
> practice to return the class that is decorated, which I think we  
> should follow, and which solves the biggest practical problems with  
> decorating. Moreover, the fact that class decorators exist indicate  
> that they are pythonic. So +1 for the decorators.
>  
> Considering the mixins: IMHO, the order of base classes shouldn't  
> matter. Can this be satisfied by the mixin-approach?
>  
> @Carl Meyer: I would opt for applying decorators *in* the class, so  
> you can still derive from it. Like::
>  
>  class MyView(View):
>  @classonlymethod
>  def as_view(cls, *args, **kwargs):
>  return login_required(super(MyView, cls).as_view(*args,  
> **kwargs))
>  
> Cheers, Roald
>  
> --  
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> 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.

Re: RFC: "universal" view decorators

[Roald de Vries]

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 decorators PEP, and I think it's very useful to  
watch (25 min.) for this discussion. According to him it is good  
practice to return the class that is decorated, which I think we  
should follow, and which solves the biggest practical problems with  
decorating. Moreover, the fact that class decorators exist indicate  
that they are pythonic. So +1 for the decorators.


Considering the mixins: IMHO, the order of base classes shouldn't  
matter. Can this be satisfied by the mixin-approach?


@Carl Meyer: I would opt for applying decorators *in* the class, so  
you can still derive from it. Like::


class MyView(View):
@classonlymethod
def as_view(cls, *args, **kwargs):
return login_required(super(MyView, cls).as_view(*args,  
**kwargs))


Cheers, Roald

--
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.

Re: RFC: "universal" view decorators

[Donald Stufft]

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  (mailto:rein...@vanrees.org)> 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
> > over because I had to jump from class to class to class to explain how it
> > all hung together.
> 
> that is my own reaction too when trying to see where in the code is
> everything that i knew from the old generic view functions.
> 
> mixins are a great way to encapsulate specific, well defined behavior;
> but tracing the code is a real chore, even so clean code as Django's.
> I guess that when you know by heart exactly what does each one do,
> they become a pleasure to use.
> 
> So, my two cents: please do the documentation first. once there's a
> single place to find exactly what the purpose, mechanism and span of
> each one, then adding more would be welcomed.
> 
> 
> -- 
> Javier
> 
> -- 
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> 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.

Re: RFC: "universal" view decorators

[Javier Guerra Giraldez]

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
> over because I had to jump from class to class to class to explain how it
> all hung together.

that is my own reaction too when trying to see where in the code is
everything that i knew from the old generic view functions.

mixins are a great way to encapsulate specific, well defined behavior;
but tracing the code is a real chore, even so clean code as Django's.
I guess that when you know by heart exactly what does each one do,
they become a pleasure to use.

So, my two cents: please do the documentation first.  once there's a
single place to find exactly what the purpose, mechanism and span of
each one, then adding more would be welcomed.


-- 
Javier

-- 
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.

Re: RFC: "universal" view decorators

[Donald von Stufft]

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 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 Reeshttp://reinout.vanrees.org/
> rein...@vanrees.org 
> 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
> .
> 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
> .
>
>

-- 
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.

Re: Should I split ticket #16502 in three tickets or not?

[Silver_Ghost]

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 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 method things should be allright in my opinion.
>
> Tino
>
> 2011/9/16 Silver_Ghost 
>
>> 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 patch (also in 
>> another ticket) for handling an empty list of candidates in 
>> `select_template`.  Is it right?
>>
>>
>> пятница, 16 сентября 2011 г. 15:12:16 UTC+6 пользователь TiNo написал:
>>
>>> 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 empty list of templates.
>>>
>>> Tino 
>>>
>>> On Thu, Sep 15, 2011 at 21:51, Aymeric Augustin <
>>> aymer...@polytechnique.org**> wrote:
>>>
 Hello,

 Yes, I think ticket #16502 should focus on the problem of CreateView: 
 why doesn't it have a default template and does it need one?

 The other issues you discovered while investigating that problem should 
 go into separate tickets.

 Best regards,

 -- 
 Aymeric Augustin.

 On 15 sept. 2011, at 09:12, Silver_Ghost wrote:

 There is a 
 commentto ticket 
 ticket 
 #16502  from *ptone*.  He 
 recommends to create two new tickets, one for get_model patch and one 
 for select_template patch.  In my opinion separating select_templatepatch 
 is a good idea while separating 
 get_model patch isn't.  This is because adding get_model method fully 
 fixes ticket #16502.

 What should I do?  If creating two new tickets as *ptone* suggests is a 
 right way then how to show relation between this three tickets?

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers" group.
 To view this discussion on the web visit https://groups.google.com/d/**
 msg/django-developers/-/zQT8_**CaxmyUJ
 .
 To post to this group, send email to djang...@googlegroups.com.
 To unsubscribe from this group, send email to django-develop...@**
 googlegroups.com.

 For more options, visit this group at 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 djang...@googlegroups.com.
 To unsubscribe from this group, send email to django-develop...@**
 googlegroups.com.

 For more options, visit this group at 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 view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-developers/-/JNNtKtXZ7LQJ.
>>
>> To post to this group, send email to django-d...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com.
>> For more options, visit this group at 
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/m9Sd5JMgBGwJ.
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.

Re: RFC: "universal" view decorators

[Reinout van Rees]

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 Reeshttp://reinout.vanrees.org/
rein...@vanrees.org 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.
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.

Re: Should I split ticket #16502 in three tickets or not?

[TiNo]

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
method things should be allright in my opinion.

Tino

2011/9/16 Silver_Ghost 

> 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 patch (also in
> another ticket) for handling an empty list of candidates in
> `select_template`.  Is it right?
>
>
> пятница, 16 сентября 2011 г. 15:12:16 UTC+6 пользователь TiNo написал:
>
>> 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 empty list of templates.
>>
>> Tino
>>
>> On Thu, Sep 15, 2011 at 21:51, Aymeric Augustin <
>> aymeric@polytechnique.org**> wrote:
>>
>>> Hello,
>>>
>>> Yes, I think ticket #16502 should focus on the problem of CreateView: why
>>> doesn't it have a default template and does it need one?
>>>
>>> The other issues you discovered while investigating that problem should
>>> go into separate tickets.
>>>
>>> Best regards,
>>>
>>> --
>>> Aymeric Augustin.
>>>
>>> On 15 sept. 2011, at 09:12, Silver_Ghost wrote:
>>>
>>> There is a 
>>> commentto ticket 
>>> ticket
>>> #16502  from *ptone*.  He
>>> recommends to create two new tickets, one for get_model patch and one
>>> for select_template patch.  In my opinion separating select_templatepatch 
>>> is a good idea while separating
>>> get_model patch isn't.  This is because adding get_model method fully
>>> fixes ticket #16502.
>>>
>>> What should I do?  If creating two new tickets as *ptone* suggests is a
>>> right way then how to show relation between this three tickets?
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To view this discussion on the web visit https://groups.google.com/d/**
>>> msg/django-developers/-/zQT8_**CaxmyUJ
>>> .
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> To unsubscribe from this group, send email to django-develop...@**
>>> googlegroups.com.
>>>
>>> For more options, visit this group at 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-d...@googlegroups.com.
>>> To unsubscribe from this group, send email to django-develop...@**
>>> googlegroups.com.
>>>
>>> For more options, visit this group at 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 view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/JNNtKtXZ7LQJ.
>
> 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.
>

-- 
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.

Re: RFC: "universal" view decorators

[Daniel Moisset]

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 only way to modify a
> function is to wrap it, so decorators provide a shortcut to do so.
>
> 2) There's already a standard way to add functionality to a class that has
> existed for a long time, is well tested, and as a bonus is something that
> people new to python but not new to programming will understand immediately.
>

I like the arguments here. On the other hand, I like Jacob's

«I'd like to convert all the view decorators built into Django to be
"universal" -- so they'll work to decorate *any* view, whether a function,
method, or class»

So what about providing something roughly like:

###
class LoginRequired():
# magic to check for user credentials, in a CBV style
...
def __call__(self, wrap_me):
# standard magic to apply the CBV decoration to a standard function
# This might also include Jacob's trick to work with methods too
...

login_required = LoginRequired # backwards compatibility
###

Actually that implementation of __call__ is probably the same for every
decorator, so Django can provide something more like:

###
from django.something import BaseViewDecorator
class LoginRequired(BaseViewDecorator):
# magic to check for user credentials, in a CBV style
...

login_required = LoginRequired # backwards compatibility
###

With that, user code can look like:

class SomeProtectedView(LoginRequired, TemplateView):
... as usual...

@login_required()
def some_other_protected_view(request, arg1, arg2):
as usual...

class NotAView():
@login_required()
def view_method(self, request, arg1, arg2):
   ... as usual ...

Which uses the "obvious" way of extension (decorators for functions/methods
and Mixins for classes) in each case (i.e., what Donald wants), but allows
implementing the decorator once, and not having to have specific wrappers
for each kind of view (universality, like Jacob wants).

This is a rough proposal to put another idea on the table, I know there's
the gotcha of the "login_required = LoginRequired" (which is to keep
backwards compatibility. Other alternative is rename the class to a non-PEP8
lowercase name). And I know there's the gotcha of having to use
login_required() instead of just login_required[1].

Does this sound like a good compromise between both positions?

Regards,
   Daniel

[1] I always found a bit irritating and antipythonic to have @login_required
as an alias for login_required() ; or in general, the behavior for
decorators with optional args, which besides needs to be coded explicitly
(DRY violation!) to behave like standard decorators. I know that changing
that would break a lot of code, and it's a story for another ticket, but I
couldn't miss the chance to complain :)

-- 
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.

Re: Should I split ticket #16502 in three tickets or not?

[Silver_Ghost]

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 patch (also in 
another ticket) for handling an empty list of candidates in 
`select_template`.  Is it right?

пятница, 16 сентября 2011 г. 15:12:16 UTC+6 пользователь TiNo написал:
>
> 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 empty list of templates.
>
> Tino 
>
> On Thu, Sep 15, 2011 at 21:51, Aymeric Augustin <
> aymeric@polytechnique.org> wrote:
>
>> Hello,
>>
>> Yes, I think ticket #16502 should focus on the problem of CreateView: why 
>> doesn't it have a default template and does it need one?
>>
>> The other issues you discovered while investigating that problem should go 
>> into separate tickets.
>>
>> Best regards,
>>
>> -- 
>> Aymeric Augustin.
>>
>> On 15 sept. 2011, at 09:12, Silver_Ghost wrote:
>>
>> There is a commentto 
>> ticket ticket 
>> #16502  from *ptone*.  He 
>> recommends to create two new tickets, one for get_model patch and one for 
>> select_template patch.  In my opinion separating select_template patch is 
>> a good idea while separating get_model patch isn't.  This is becauseadding 
>> get_model method fully fixes ticket #16502.
>>
>> What should I do?  If creating two new tickets as *ptone* suggests is a 
>> right way then how to show relation between this three tickets?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-developers/-/zQT8_CaxmyUJ.
>> To post to this group, send email to django-d...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com.
>> For more options, visit this group at 
>> 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-d...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com.
>> For more options, visit this group at 
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/JNNtKtXZ7LQJ.
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.

Re: RFC: "universal" view decorators

[Roald de Vries]

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 breaks the  
basic
invariant "issubsclass(decorator(A), A) == True". This is  
important if

you're planing to use this as "B = decorator()(A)" (and you are,
'cause the whole point of not modifying the original class is to  
allow

safely doing this), as you quickly end up with weird alternate
hierarchies. So, please don't do that :)


I agree that in an ideal world we'd have a better solution. On the  
other
hand, the cbv-decorator using inheritance just didn't work, and the  
one
using shallow copies does (if you don't use B=decorator()(A),  
indeed).


The one that just alters the given class also works, has no magic and
has the same limitation - dont' do "B = decorator(A)".


To show that this is actually a Python-thing, an analogous non- 
decorator-example:


>>> class A(Base):
... def method(self, *args, **kwargs):
... super(A, self).method(*args, **kwargs)
...
... B = A
... A = SomeOtherClass
...
... B.method()
Traceback (most recent call last):
...
TypeError: unbound method method() must be called with A instance  
as first argument (got nothing instead)


So IMHO it's "pythonic" to leave responsibility to use the decorator  
in the right way to the programmer.


Cheers, Roald

--
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.

Re: RFC: "universal" view decorators

[Mikhail Korobov]

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 one way to do something and 
this way can't be mixins because they can't work with functions. Decorators 
can work with classes, this is standard python and it will be nice to have 
them work with class-based views.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ZCeB1UehSSQJ.
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.

Re: RFC: "universal" view decorators

[Łukasz Rekucki]

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 ugly. It's mainly because I
>> was focus on how to reuse existing decorators in CBV context. It
>> shouldn't be to hard  to make the "view_decorator" a meta-decorator
>> (or a factory function as you call it) that turns login_required to
>> something that is both a class and function decorator. Methods are
>> still out-of-bounds for non-runtime introspection, but after almost 1
>> year of using CBV, I never needed to decorate a method.
>>
>> 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 breaks the basic
>> invariant "issubsclass(decorator(A), A) == True". This is important if
>> you're planing to use this as "B = decorator()(A)" (and you are,
>> 'cause the whole point of not modifying the original class is to allow
>> safely doing this), as you quickly end up with weird alternate
>> hierarchies. So, please don't do that :)
>
> I agree that in an ideal world we'd have a better solution. On the other
> hand, the cbv-decorator using inheritance just didn't work, and the one
> using shallow copies does (if you don't use B=decorator()(A), indeed).

The one that just alters the given class also works, has no magic and
has the same limitation - dont' do "B = decorator(A)". Honestly, I
never needed that, but I understand some people might. Also note, that
the "super() problem" is fixed in Python 3, where super() determines
the base class from the call frame instead of referencing a global
variable.

>
> If this doesn't exist, then the view_decorator still has a right to live.
>
> So what would have to be created is a meta-decorator universal_decorator,
> replacing or using view_decorator, such that
> universal_decorator(login_required) is the actual universal decorator. This
> would be applied to all django-decorators, but I think it would be good to
> also allow applying universal_decorator to an already universal decorator,
> such that:
>
>    # after this...
>    login_required = universal_decorator(login_required)
>    # ... this will hold
>    assert login_required == universal_decorator(login_required)
>
>

+1

-- 
Łukasz Rekucki

-- 
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.

Re: RFC: "universal" view decorators

[Łukasz Rekucki]

> 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 introducing CBV. It
didn't gain much love.

-- 
Łukasz Rekucki

-- 
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.

Re: Should I split ticket #16502 in three tickets or not?

[TiNo]

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 empty list of templates.

Tino

On Thu, Sep 15, 2011 at 21:51, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> Yes, I think ticket #16502 should focus on the problem of CreateView: why
> doesn't it have a default template and does it need one?
>
> The other issues you discovered while investigating that problem should go
> into separate tickets.
>
> Best regards,
>
> --
> Aymeric Augustin.
>
> On 15 sept. 2011, at 09:12, Silver_Ghost wrote:
>
> There is a commentto 
> ticket ticket
> #16502  from *ptone*.  He
> recommends to create two new tickets, one for get_model patch and one for
> select_template patch.  In my opinion separating select_template patch is
> a good idea while separating get_model patch isn't.  This is becauseadding
> get_model method fully fixes ticket #16502.
>
> What should I do?  If creating two new tickets as *ptone* suggests is a
> right way then how to show relation between this three tickets?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/zQT8_CaxmyUJ.
> 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.
>
>
>  --
> 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.
>

-- 
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.

Re: RFC: "universal" view decorators

[Anssi Kääriäinen]

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 my own 'decorators' in this approach?

Cheers, Roald


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')]


The difference to actually decorating the class is small, but I think 
the above is a bit more explicit about what is happening.


Mixins sound like a good alternative, but does this just move the 
problem in to mixin class instead of the base view class? That is, how 
should the mixin class be implemented taking in account that you should 
be able to decorate the function with multiple decorators? It seems you 
would need something like ViewDecoratorMixinBase to take care of all the 
dirty details...


 - Anssi

--
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.

Re: CSRF protection and cookies

[Kent Engström]

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 protection is mostly free.

Of course. The sites I'm thinking of are HTTPS only. 

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?

Thanks for your work on this,

/ Kent Engström

-- 
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.

Re: RFC: "universal" view decorators

[Roald de Vries]

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, Roald

--
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.

Re: RFC: "universal" view decorators

[Roald de Vries]

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

   @class_view_decorator(login_required)
   class MyView(View):
   ...

This makes me less sad, but still sad. Factory functions. Ugh.


As the ticket creator I feel obligated to reply :)


Me (as the poster of the latest patch) too :)


Thinking about it now, it does look kinda ugly. It's mainly because I
was focus on how to reuse existing decorators in CBV context. It
shouldn't be to hard  to make the "view_decorator" a meta-decorator
(or a factory function as you call it) that turns login_required to
something that is both a class and function decorator. Methods are
still out-of-bounds for non-runtime introspection, but after almost 1
year of using CBV, I never needed to decorate a method.

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 breaks the basic
invariant "issubsclass(decorator(A), A) == True". This is important if
you're planing to use this as "B = decorator()(A)" (and you are,
'cause the whole point of not modifying the original class is to allow
safely doing this), as you quickly end up with weird alternate
hierarchies. So, please don't do that :)


I agree that in an ideal world we'd have a better solution. On the  
other hand, the cbv-decorator using inheritance just didn't work, and  
the one using shallow copies does (if you don't use B=decorator()(A),  
indeed).


As Donald mentioned, the more elegant solution for classes is to use  
base classes (mixins) instead of class decorators. I'm not sure though  
if every decorator can be replaced by a mixin, and if the order of  
these mixins can be arbitrary in that case (which I believe is  
desirable). Can anybody comment on that?



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] if the view's a method. This
technique won't work for any old decorator, but it *will* work (I
think) for any decorator *designed to be applied only to views*.


+1 on this. I would be a bit concerned about this vs. future
implementation of generator-based-views that allow some kind of
response streaming (is someone working on that?).


I've written a proof-of-concept patch to @login_required (well,
@user_passes_test, actually):

   https://gist.github.com/1220375


Did I already mention creating a subclass in the class decorator
breaks super ;) [https://gist.github.com/643536]

Can I get some thoughts on this technique and some feedback on  
whether

it's OK to apply to every decorator built into Django?


It would be great to have that meta-decorator, so everyone else could
upgrade their decorators just by decorating them.


If this doesn't exist, then the view_decorator still has a right to  
live.


So what would have to be created is a meta-decorator  
universal_decorator, replacing or using view_decorator, such that  
universal_decorator(login_required) is the actual universal decorator.  
This would be applied to all django-decorators, but I think it would  
be good to also allow applying universal_decorator to an already  
universal decorator, such that:


# after this...
login_required = universal_decorator(login_required)
# ... this will hold
assert login_required == universal_decorator(login_required)







--
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.

Re: RFC: "universal" view decorators

[Jonathan Slenders]

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 prefer a more declarative approach,
like this:

class ProtectedView(MyView):
login_required = True

Where 'MyView' checks all the view's options during a dispatch. Never
liked inheritance with multiple base classes...

-- 
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.

Re: RFC: "universal" view decorators

[Jonas H.]

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 harder and/or uglier, and goes against the way functionality is
currently added to a CBV.


That sounds a lot better to me.

--
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.