On Feb 3, 7:49 pm, Łukasz Rekucki <[email protected]> wrote: > On 3 February 2011 18:06, Jari Pennanen <[email protected]> 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 from my experience, but I may be > biased.
Yes, it would be a good thing if one could say when the view is final, but in python there is no final classes. > I'm not saying, that having a permission checking mixin > is a bad idea, but I don't like the proposed API. For starters, you > mentioned "object permissions" - how do I check that in your > implementation, if all checkers are evaluated in dispatch() (and > without fetching the object multiply times) ? Yes I noticed the get_object() does not cache, which it probably should do. Additionally my checkers does not take in account the *view*. To make object permission checkers they should be more general like func(view, request, *args, **kwargs) -> bool. This way they could access the view.get_object()... > It's actually a shortcut for user_passes_test() decorator factory and > a very short lambda, so there is not much to reuse (apart from the > redirection code maybe). But underlying reusable part is either in form of func(user) -> bool, or func(request) -> bool. > > 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. > > Yes, I know it's possible and I even showed you that exact > implementation. It's not exactly "add only" as you can always override > `get_decorators()` to filter out or replace the list entirely. I'm sorry I did not watch your code earlier, I just rambled as I have used similar way for my QuerySet basing (entirely different thing). So what you are saying is that you guys cooked up already something I'm reimplementing, list of decorators that can be overridden or used as add only. Now we just need the decision what to use! > Without the add semantics, every time I want to add a check, I need to > repeat all the checks in base classes, which is not very DRY if you > ask me. If the checks come from a 3rd party app and it ever changes, I > would need to go through all my code and update the lists. In the end there probably is like three permission checks in "worst" case scenario, so we are arguing over a very little improvement even if it were overridable or only defined in final-like class. > Maybe your mixin could provide a method to run the checks (so the view > can decide when to invoke it) and some other methods which do the > actual checks that can be overridden. Just a thought. Could be, in the end all I care is that I would not need to write lot of boiler plate code, or utility libraries. And more than anything I hate the fact that there is no single decision to choose class method decorators or anything else *shorter*. (E.g. I just discovered that get_or_404 is included in django, I wonder how long it took to be made. I've been dreaming for a long time for Model.objects.get_or_404, but I think module level will do too. So this is one less utility function I need to "maintain".) -- 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.
