On Feb 3, 2:16 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen <jari.penna...@gmail.com> 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 happy for class decorators too, as long as it is simpler. > To my mind, this isn't quite the same as setting template_name. That's > a simple configuration issue, not something that fundamentally alters > view behavior. To reinforce the point -- as an alternative to > specifying template_name, you can override the function > get_template_names() which programatically returns the right template. > It would strike me as strange for the list of decorators to be applied > to a view to be configured in the same way. Yet it would be > contradictory to have some class variables extendable by function, but > not others. This forbidden_checks is not list of decorators, just functions that checks the request/input if the view is allowed to view. Secondly why couldn't there be get_forbidden_checks() getter too if that is the problem? 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. I can't see those other attributes any less important, shit will break if one changes them unless changing other parts too (usually). -- 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.
