On 3 jun, 19:33, Luke Plant <l.plant...@cantab.net> wrote: > On Thursday 03 June 2010 08:59:31 Roald wrote: > > > One reason against this is it makes it harder to re-use other > > > views from within the View. > > I don't really understand what you mean. Do you mean re-using > > 'good' old function-views? > Yes, or new ones, or any callable that returns an HttpResponse that I > want to return. It is quite a common pattern to have one view wrap > another or *several* others, and also to use standard response objects > in some utility function or 'sub view'. e.g. > > def my_view(request, *args): > if some_condition(): > return some_view(request, *args) > elif other_condition(): > return some_standard_response(request.user) > else: > ... > return render_to_response(...) > > def some_standard_response(user) > return HttpResponseRedirect(...) > > This would be massively uglified, at best, if we make View a subclass > of HttpResponse.
You're right, I wouldn't know how to do this with __init__, and I think I would choose for a simple function, or maybe __new__. On the other hand: is that a problem? These classes are a solution to a problem that I have with a lot of my views, but not with all. It's not necessary to make every view a class. -- 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.
