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 User.user_permission and subclass could require using per object permission. What would happen now? The programmer could not subclass from that class only because the permissions checking is enforced in super class but otherwise a good class, not exactly a good solution. So I think the overriding ability in subclasses is a good to have. On Feb 3, 6:15 pm, Lukasz Rekucki <lreku...@gmail.com> wrote: > On 3 February 2011 16:09, Jari Pennanen <jari.penna...@gmail.com> wrote: > If they're not decorators, then that's even worse, 'cause you need to > duplicate all existing permission checking decorators. In fact current decorator permission checking mechanism is wrong, it does two things in one function: Checking permissions from request (what I propose to separate) and being decorator at the same time. They break the principle of one function one task, and should be breaken apart to checker functions and decorators. Similarly as validator functions are separated and reusable. This is what I said in my ticket that *checker* functions are reusable in decorators (not otherway around.) > 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. Making the attribute to *add only* is possible (but I don't support that because of need to override I said above), by iterating over classes (in __mro__*) and combining the checker functions to one list. However I find that would be odd behavior for class/instance attribute. Also programmer should be able to remember all the checker functions in all superclasses, and the overriding the earlier values becomes impossible (or requires other way to do it). *One can iterate over classes in mro order using e.g. inspect.getmro(). -- 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.
