On Thu, Jun 17, 2010 at 3:35 PM, Johannes Dollinger <johannes.dollin...@einfallsreich.net> wrote: > 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. > >
So here's an idea, of dubious quality ;) Only pass request around to methods, and have a requests dictionary on the view (which is instantiated once) then methods can use that dict to store data in it. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
