Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: > I've just added a summary of the last thread on class-based views [1]. > This summary isn't 100% complete -- any contributions from interested > parties are welcome. Try to keep opinions to a minimum; this page is > about documenting the strengths and weaknesses of various approaches, > not about expressing opinions. In the same way that CSRF [2] and > session-messages [3] have good wiki pages describing the design > considerations, we need to be able to explain to future generations > why class-based views are the way they are.
Could you (or anyone knowledgable) add a section, that explains why each request should have its own view instance? The thread-safety argument alone does not suffice: if all _request_ state would be stored on request instead of the view, you wouldn't need new instances per request. You could also pass around state explicitly - which admittedly gets messy quickly. So is this purely about preventing users from shooting themselves in the foot? (hyperbole: Will there be protection from globals in django 1.4?) > Based on the discussion on the most recent thread [4], plus in-person > discussions, I'm proposing that we move forward with Ben Firshman and > David Larlet's "__call__ + copy()" approach. Yes, the copy() is a bit > of a weird idiom, but it's not an idiom that users need to be > particularly concerned with; the code "just works" in an unsurprising > way. I disagree. If you define a class-based view, create an instance (a singleton) and put it in your urlconf, you wouldn't (or shouldn't) expect it to magically reinstantiate itself everytime it's called. So at least the docs will have to point out the magic prominently. Regardless of my resentments, thanks for finally creating an official foundation for class based views. __ 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.
