Luke, you're absolutely right that changing the definition of a view is a bad idea, it just seemed the best solution then.
But don't worry, we've changed our minds again! If __call__() creates a copy of self and calls methods on the copy, as far as I can see it solves all our problems. No boilerplate, and it's really hard to make it unsafe thread-wise. An example of how it could work: http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/base.py Thanks Ben On 29 May 2010, at 00:07, Luke Plant wrote: > On Friday 28 May 2010 15:51:32 Jacob Kaplan-Moss wrote: > >> My only real objection here is that `as_view` is just a bunch of >> boilerplate:: >> >> urlpatterns = patterns('', >> ('one/', SomeView.as_view()), >> ('two/', SomeOtherView.as_view()), >> ('three', YourView.as_view()) >> ) >> >> I just really don't like the way that looks. > > Agreed. I also think that if you have a mixture of normal views and > class based view, this is ugly: > > urlpatterns = patterns('app.views', > ('one/', 'some_view_function', > ('two/', SomeOtherView), > ('three/', YourView) > ) > > and it would be nicer to spell it: > > urlpatterns = patterns('app.views', > ('one/', 'some_view_function'), > ('two/', 'some_other_view'), > ('three/', 'your_view') > ) > > and have these additional lines in 'app.views': > > some_other_view = SomeOtherView.as_view() > your_view = YourView.as_view() > > I know that is just moving the boilerplate around, but it is giving a > consistent interface. If some code in a re-usable app moves from > normal views to class based views, they will have to do something like > this *anyway* for backwards compatibility. > > But I can see that if subclassing is the default way of re-using, then > exporting these functions gives multiple options about how they should > be re-used, which you are wanting to avoid. > >>> There is also the issue of what to do when you need to add a >>> decorator to someone else's view function. >> >> Again, I want to encourge "subclass it" as the correct answer here. > > In that case, I guess it would be good to make this hard to do wrong, > by providing helpers that add the decorator to the right end of the > list of decorators. > > Regards, > > Luke > > -- > "Oh, look. I appear to be lying at the bottom of a very deep, dark > hole. That seems a familiar concept. What does it remind me of? Ah, > I remember. Life." (Marvin the paranoid android) > > 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. > -- 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.
