On 3 February 2011 16:09, Jari Pennanen <[email protected]> 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, **initkwargs):
return fdec(original(current, **initkwargs))
cls.as_view = classonlymethod(as_view)
return cls
return decorator
Using this transformer, you can decorate classes just like normal
views. It's simple and not-magical. The only drawback is that it
modifies the given class, so it can't be used "in-place", so it didn't
make it (Although, I'm using it quite successfully for some time now
in my projects and we didn't had any trouble with it yet). Other
version was to create a subclass "on-the-fly", but it turned out to be
even more dangerous.
>
> This forbidden_checks is not list of decorators, just functions that
> checks the request/input if the view is allowed to view.
If they're not decorators, then that's even worse, 'cause you need to
duplicate all existing permission checking decorators.
> Secondly why
> couldn't there be get_forbidden_checks() getter too if that is the
> problem?
Something similar was already proposed earlier by Luke Plant and I
made an example implementation that takes MRO into account:
https://github.com/lqc/django/commit/ef7a7adfb72c79e4c0068841e4b71ac27c138b28
It does work quite nicely, but as Russell said - it's a magic
attribute, a bit like the Meta class in models, but worse as it
duplicates the idea of class decorators.
>
> I personally don't find this behavior surprising. If there really is
> something fundamentally different with forbidden_checks and other
> class attributes like model, queryset, template_name,
> context_object_name, ... then there has to be a way to define the
> difference.
things like `template_name` or `model` just overwrite whatever was
previously defined in the base classes. In case of permission checks,
you will most likely want to *add* checks, not overwrite. Also, if I
have 2 views/mixins that do some checks (which most likely are
required for proper operation of those views/mixins), then if I
inherit from both, my subclass should do all those checks, not only
part of them.
--
Ł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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
