We have the following constraints: 1. Django supports class-based views.
2. Django supports function-based views (ultimately these are the same thing, which is that Django supports anything as a 'view' so long as it's callable, accepts an HttpRequest as its first positional argument when being called and either returns an HttpResponse or raises an exception). 3. The natural way to add processing in/around a class is subclassing and either overriding or mixing in. 4. The natural way to add processing in/around around a function is decorating. Any solution to this needs to address those constraints, and allow code to look and feel natural. Based on that, some arrangement which allows the same basic logic to exist in a "mixin" (I dislike that word) for classes and a decorator for functions seems most appropriate, even if it does mean having two ways to do things -- that's a distinction I think we can live with, as people will appreciate that it doesn't result in strange-looking code. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- 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.
