2010/6/17 Ian Lewis <ianmle...@gmail.com>: > Attaching all kinds of stuff to self tends to depend on the order of > the methods called and allows for some ugly coding styles. In that > case the slightly strange idea of merging the request and the view by > extending HttpRequest starts to make sense since otherwise you would > have some state on the request object (like the user etc. as it is > now) and some state on the view object. My view is that request=="input data", view class=="execution" and view instance=="execution environment". Function-based views are pretty much the same, but you just don't have to care about the environment, because it's composed out of your local variables.
> > That said, both extending HttpRequest and using __new__ seem like a > hacks to me. Personally the idea of a view being a callable class > instance or method is simple and flexable enough to handle any use > cases we are talking about. You just have to think of self as the > *view* rather than a thread safe request because that's what it is. I agree about HttpRequest. As Tom pointed out Request is not a View. It just doesn't fit the inheritance. As for the __new__, I guess it's just two diffrent approaches and in the end you get pretty much the same thing. I think of "self" as "environment" and the class as "view". In one instance approach, the instance is the "view" and "environment" is in method parameters or request (is this right?). Anyway, I think this discussion in on a wrong track. From a Django user POV, I really don't care how it's implemented. I'm far more concerned with the API that generic views will provide. -- Łukasz Rekucki -- 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.
