No my point is that the proposed solution: https://docs.djangoproject.com/en/1.8/topics/class-based-views/intro/#decorating-in-urlconf
will couple logic inside the urlconf and the methodology itself tend to create hard to read code. Still I think it makes sense to choose to wrap the *Klass.as_view()* over creating mixin or using *method_decorators* mostly because you can add logic to a class without actually alter its definition. I think it would be better to have a small function in utils that accepts an iterator of functions and a class with an *as_view()* class method in order to do something similar to what I do with the reduce: from django.utils.decorators import decorate_class_view awesome_view = decorate_class_view(KlassView, list_of_decorators) Alternatively I propose to change the documentation and add the reduce syntax or an equivalent, and not advise to decorate inside the Urlconf. On Thursday, August 6, 2015 at 2:03:50 PM UTC+2, Tim Graham wrote: > > A few days ago, we added the ability to use @method_decorator at the class > level: > > > https://github.com/django/django/commit/3bdaaf6777804d33ee46cdb5a889b8cc544a91f1 > > Does it help? > > Is your proposal to add the reduce() syntax to the docs? > > On Thursday, August 6, 2015 at 7:21:36 AM UTC-4, Fabrizio Messina wrote: >> >> Hello I would like to ask why the class based views documentation seems >> so much ugly. Some developers probably are scared by these just because the >> decoration is ugly, the documentation offers three ways: >> >> Decorate the *Klass().dispach()* method of the class, wrapping the >> decorators in another decorator: >> >> @method_decorator(decorator_1) >> def dispatch(request, *args, **kwargs): >> pass >> >> Wrapping the *Klass.as_view()* resulting in an arguably ugly >> >> *:* >> >> >> *decorator_1( decorator_2( .. ( .. decorator_n( Klass.as_view() ) .. ) .. >> ))*In my opinion this is an issue because decoration is actually cool and >> the >> alternative is to use the much more dreadful Multiple Inheritance, that is >> the documented third way. >> >> >> I personally use reduce syntax: >> >> view = reduce(lambda x, f: f(x), (decorator_1, decorator_2, .., >> decorator_n), Klass.as_view()) >> >> Probably there are better ways but still to me it seems to me that >> something like this is more readable, easier to modify and less scary. To >> me it has the pro that one could easily wrap common used decorators in a >> single iterable. >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6a8bfa50-5f54-4198-bf79-5afb9ee7078a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
