On Tue, 2010-10-05 at 09:43 -0500, Jacob Kaplan-Moss wrote: > One point of concern that came up though: looking at the way as_view > introduces a closure, it occurs to me that the docstring of am > as_view'd class view isn't very useful, which'll break introspection > and things like the admindocs tool. And just using functools.wraps (or > the equivalent) is as_view won't exactly work, either: you'll get the > dispatch() docstring instead. > > So unless anyone can think of a reason why it'd be a bad idea, I think > as_view needs to monkeypatch the class's docstring into the returned > closure. Bit of a code smell, but I think it maintains the correct > self-documenting nature of a view, yeah?
Sounds fine to me, and I think it should also copy other function attributes from the dispatch method, to allow people to apply decorators like 'csrf_exempt' to the dispatch method and have it work as expected. We might like to think about whether we add any other mechanism for decorators. We already have the ability to decorate the result of 'as_view()', which is best suited for things like 'cache_page', and to decorate methods like dispatch, which is best suited for decorators that are required for the view to work correctly. A list of decorators could also be specified as a class/instance attribute and added inside the 'as_view' to the closure that is returned. For the moment, I think adding this would add too many choices, and if there is a need for it we can add it as a feature later. Luke -- "Doubt: In the battle between you and the world, bet on the world." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
