Sorry in my previous email you could simply pass the uninstantiated class in the url pattern.
url(r'...',MyOOView,...) On Sat, Oct 2, 2010 at 8:57 AM, David P. Novakovic <davidnovako...@gmail.com> wrote: > My problem with all of this is that it feels like a hell of a lot of > hoopjumping to deal with something that could be solved in the > Resolver. > > I may be missing something obvious here, so please tell me if I am.. > but couldn't the resolver just check that quacks like something > OOViewish has been passed in and simply branch and init the class > before calling the view in the same way it normally would? > > pseudo code follows: > > obj = None > func = None > if hasattr(view,something_an_ooview_has): #general ooview instance checking > obj = view() > func = view.dispatch > else: > func = view > > response = func(...) > return response > > > D > > On Sat, Oct 2, 2010 at 4:14 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: >> >> On Oct 1, 4:16 pm, Russell Keith-Magee <russ...@keith-magee.com> >> wrote: >> >>> "Don't use instance variables on a class" isn't advice you're going to >>> see printed very often. Yet that would be the advice that would be >>> *required* in order to use stateless class-based views in the way you >>> describe. >>> >>> Objects have state. I don't think it's at all unreasonable to suggest >>> that a instances of a class based view should be able to have state. >>> And even if we documented the fact that they can't have state, I'm >>> willing to *guarantee* that people will *try* to make them stateful. >>> >> >> To perhaps complicate the issue a little further, I think there's a >> distinction between read-only state and mutable state. It seems >> reasonable to let view class instances have read-only state (this >> might be part and parcel of increased [re]usability) such as template >> names, output mimetype configuration etc. This would be quite safe, >> ISTM. >> >> For mutable state during request processing, I'd vote for sticking it >> all in the request. Then your method signatures need only include the >> request - not unreasonable - and if for some reason you couldn't do >> that, there's always thread locals for the requests (duck ;-)) >> >> Regards, >> >> Vinay Sajip >> >> -- >> 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.
