Maybe I missed something, but why don't you use __new__ instead of copying the instance?
Bye, Waldemar On May 29, 11:06 pm, Ben Firshman <b...@firshman.co.uk> wrote: > 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_b... > > 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 > > athttp://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.
