On 3 February 2011 18:06, Jari Pennanen wrote:
> If everyone is happy with class decorators we should do it. But bear
> in mind that removing the ability to override them practicly means
> that only Final class should define them.
Which I think is actually a good thing
If everyone is happy with class decorators we should do it. But bear
in mind that removing the ability to override them practicly means
that only Final class should define them.
That could lead to following annoying situations: Base classes could
e.g. enforce using some requirement for
On 3 February 2011 16:09, Jari Pennanen wrote:
>
> But I would be happy for class decorators too, as long as it is
> simpler.
def view_decorator(fdec):
def decorator(cls):
original = cls.as_view.im_func
@wraps(original)
def as_view(current,
On Feb 3, 2:16 pm, Russell Keith-Magee
wrote:
> On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen wrote:
> The pair of Ls in my email address aren't just there for show. Russell. Two
> Ls.
I'm terribly sorry, that was unintentional.
But I would be
On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen wrote:
> "Meh - this seems like reinventing a syntactic wheel to me. Python
> 2.6
> has class decorators." - Russel
The pair of Ls in my email address aren't just there for show. Russell. Two Ls.
> Why to use decorators?
"Meh - this seems like reinventing a syntactic wheel to me. Python
2.6
has class decorators." - Russel
Why to use decorators? They cannot be overridden neatly in subclasses,
see my above gist about this subclassing.
--
You received this message because you are subscribed to the Google Groups
Here is now subclassed from View, and checked that overriding works:
https://gist.github.com/809208
--
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
I noticed that it is safer to subclass ForbiddenMixin from View
because of MRO: https://gist.github.com/808516
If it is subclassed from View, then above would throw error and one
could not even define them in wrong order: AuthedViewSecond(View,
ForbiddenMixin):
--
You received this message
I opened up a ticket http://code.djangoproject.com/ticket/15215 in
order to make the class based view permission checking easier.
I don't know do other think that they need to be easier to check, but
I think following API would be simple:
class ProtectedView(TemplateView, ForbiddenMixin):