I've been keeping up with this thread but have not had the time to respond until now. I will endeavor to keep it brief as this thread has grown quite long!
+1 on using a single dispatch() method rather than hard-coding HTTP method dispatch. As was pointed out, there are many possible dispatch patterns to fit different applications, and they can be implemented in subclasses. Regarding thread safety, I fear that there may be two separate concerns being conflated in the conversation. When I hear "thread safety" I think "preventing accidental sharing of data between two requests running at the same time". In an HTTP application there is a second concern that I might call "HTTP state safety" which is "preventing accidental sharing of data between two requests running at different times". HTTP is designed to be a stateless protocol, and some of the most insidious and expensive bugs to find and fix are the ones where request state *accidentally* leaks from one request to a subsequent request. For this reason, any good web development framework should make it *very hard* to leak state between requests. (If you *want* to share state between requests, Django provides obvious ways for you to do that already: Models and Sessions.) We seem to have two competing concerns: the desire to pass arguments to the view constructor (which argues for a single instance), and the natural tendency for developers to store request state on the view instance (which argues for instance-per-request). This sounds like a job for a Factory Class, doesn't it? What if you instantiate a ViewFactory in your urls.py, passing it all the arguments you want to initialize your view instance. At request time, the ViewFactory instance creates a new View instance, initializing it with the arguments it stored. It then becomes safe for View instances to store request state, but they are still initialized as desired. Is this safer than a shallow copy of a live instance? Discuss. -- 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.
