Am 17.06.2010 um 18:23 schrieb Ian Lewis:
The example he provided isn't terribly good but you don't need an view
instance per request (the example will work unless you start adding
stuff to self or overwriting self.qs etc). Only shared state is stored
at the class level and view customization is done at the class
instance level as well. That state shouldn't change.
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.
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.
Having a view object per request makes no sense. You should have a
request object per request. It is largely a result of wanting the
convenience of being able to write sloppy code that writes all kinds
of state to self rather than a technical necessity.
Ian
I'd like to support Ian and Patryk's position: class based views
should not be instantiated for each request - for all the reasons Ian
gave in the quoted mail.
If you want to avoid passing around (lots of) arguments between
methods, you can always store request specific state on the request
instance, which is a common pattern for middleware already.
To prevent the request's dict from becoming too cluttered, simply put
the arguments into `request.view_context` (a dict or similar
container, needs to be painted).
__
Johannes
--
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.
