On Thu, May 3, 2012 at 4:25 PM, Stephen Burrows
wrote:
> I was recently working with django's syndication framework, and noticed that
> it felt clunky in a lot of ways. For example, I can only access the request
> and the kwargs for the function during the get_object method; if I want to
> do anyt
I was recently working with django's syndication framework, and noticed
that it felt clunky in a lot of ways. For example, I can only access the
request and the kwargs for the function during the get_object method; if I
want to do anything more complicated with them - for example, say I want to
Taking my best guess I removed the attribute based method from my
patch and uploaded a new one[1]. Would be good to know if there is
something obviously broken about my patch.
[1]: http://code.djangoproject.com/ticket/14512
Cheers,
Łukasz Rekucki
--
You received this message because you are sub
Hi,
I just added a patch to this ticket. It includes 2 solutions:
First one is an implementation of Luke's idea with a class attribute.
You just define an sequence:
class MyView(View):
decorators = [login_required, never_cache]
# MyView.as_view === login_required(never_cache(View.as_v
On 21 October 2010 16:53, Luke Plant wrote:
> On Thu, 2010-10-21 at 15:02 +0200, Łukasz Rekucki wrote:
>
>> > Good catch! The attached patch should fix it, but it feels a bit icky,
>> > due to the double application of the decorator. Let me know if it solves
>> > this problem for you, or if you c
On Thu, 2010-10-21 at 15:02 +0200, Łukasz Rekucki wrote:
> > Good catch! The attached patch should fix it, but it feels a bit icky,
> > due to the double application of the decorator. Let me know if it solves
> > this problem for you, or if you can think of a better way to fix it.
>
> I does fel
On 21 October 2010 14:31, Luke Plant wrote:
> On Thu, 2010-10-21 at 01:40 +0200, Łukasz Rekucki wrote:
>
>> On a related note, while writing a class_decorator() I noticed that
>> method_decorator() doesn't work with decorators that set attributes on
>> the view (like csrf_exempt). This is because
On Thu, 2010-10-21 at 01:40 +0200, Łukasz Rekucki wrote:
> On a related note, while writing a class_decorator() I noticed that
> method_decorator() doesn't work with decorators that set attributes on
> the view (like csrf_exempt). This is because the decorator is invoked
> on a closure inside _wra
On Thu, Oct 21, 2010 at 1:42 AM, Luke Plant wrote:
> On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote:
>
>> OTOH, it's annoying to have to write an dispatch() method with a super
>> inside (which effectively does nothing), just to apply a decorator.
>
> That's a good point I hadn't thought
On 20 October 2010 19:42, Luke Plant wrote:
> On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote:
>
>> OTOH, it's annoying to have to write an dispatch() method with a super
>> inside (which effectively does nothing), just to apply a decorator.
>
> That's a good point I hadn't thought of, as
On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote:
> OTOH, it's annoying to have to write an dispatch() method with a super
> inside (which effectively does nothing), just to apply a decorator.
That's a good point I hadn't thought of, as are Russell's other points.
Just to put it on the ta
Created a ticket for this: http://code.djangoproject.com/ticket/14512
On 20 October 2010 16:13, Russell Keith-Magee wrote:
> On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant wrote:
>> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>>
>>> A class decorator (and/or a wrapper function for
On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant wrote:
> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>
>> A class decorator (and/or a wrapper function for turning decorators
>> into class decorators) is also an interesting idea.
>
> An argument against this is "one way to do it". If
Well, since we are already using class Mixins for extending View
functionality, we can try to turn decorators into mixins. Having two
ways to add some functionality to class (decorators and mixins) can be
somewhat uncomfortable.
I had some doubts if mixins can act as a "wrappers" to defined
functi
On 20 October 2010 15:59, Luke Plant wrote:
> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
>
>> A class decorator (and/or a wrapper function for turning decorators
>> into class decorators) is also an interesting idea.
>
> An argument against this is "one way to do it". If I look
On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote:
> A class decorator (and/or a wrapper function for turning decorators
> into class decorators) is also an interesting idea.
An argument against this is "one way to do it". If I look at a class
and want to know what decorators are app
I think class decorator for views only is a great idea, because it will be:
a) just like with old view functions decorators
b) does not require any method overrides/imports into urls.py/explicit
transformations in views.py
I'd like Django to have a decorator for turning old decorators into
decora
On Wed, Oct 20, 2010 at 7:05 PM, Valentin Golev wrote:
> As far as I know, I can just say:
>
> @login_required
> class MyView(View):
> # ...
>
> since it will wrap __init__
>
> I need either to create a decorator for decorators:
> @on_dispatch(login_required)
> class MyView(View):
>
> or decorat
Almost everything I'm talking about right now is from this thread:
http://groups.google.com/group/django-users/browse_frm/thread/5239e284b5c285d5/a2676f257d37cf85#a2676f257d37cf85
("login_required and new class based views" in django-users in case
the link doesnt work.)
As far as I know, I can just say:
@login_required
class MyView(View):
# ...
since it will wrap __init__
I need either to create a decorator for decorators:
@on_dispatch(login_required)
class MyView(View):
or decorate result of MyView().as_view().
Maybe I'm wrong. I think it will be great to
On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev wrote:
> Awesome, thank you!
>
> I've asked about @login_required and class based views in
> django-users, and I'd like to ask here: are something like
> LoginRequiredMixin's planned?
No, nothing like that is planned. This is a situation were decora
ble 12:00-18:00 MSK
On Wed, Oct 20, 2010 at 4:36 AM, Russell Keith-Magee
wrote:
> On Wed, Oct 20, 2010 at 1:25 AM, Valentin Golev wrote:
>> Hello,
>>
>> I'm trying to use brand new Class Based Views and I have a question
>> about implementation.
>>
>> L
On Wed, Oct 20, 2010 at 1:25 AM, Valentin Golev wrote:
> Hello,
>
> I'm trying to use brand new Class Based Views and I have a question
> about implementation.
>
> Let's take a look at SingleObjectMixin.get_object():
> http://code.djangoproject.com/browser/dj
Sorry! I've hit "Enter" key accidentally while writing a subject.
Don't blame me too much, please :)
On 19 окт, 21:22, Valentin Golev wrote:
> Hello
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
Hello,
I'm trying to use brand new Class Based Views and I have a question
about implementation.
Let's take a look at SingleObjectMixin.get_object():
http://code.djangoproject.com/browser/django/trunk/django/views/generic/detail.py
Why does it use function arguments, and not self.kwa
Hello
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options,
Hello
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options,
27 matches
Mail list logo
