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 har
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 pr
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)
clas
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,
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.
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
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
> 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 int
On 16 September 2011 09:17, Jonas H. wrote:
> 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 findi
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 be
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 o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Łukasz,
On 09/16/2011 03:42 AM, Łukasz Rekucki wrote:
> 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 mig
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
i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My comments:
The class-decorator support isn't really universal, it's specific to
Django's built-in class-based views. This would need to be
well-documented, and the decorator should also probably check for the
existence of a "dispatch" method and say
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 p
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
> funct
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
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 a
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 whi
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 declar
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 jum
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.o
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 decora
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 nothi
> 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,
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 ca
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, ac
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
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 impl
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 functi
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.
d
31 matches
Mail list logo
