On Fri, Oct 1, 2010 at 11:20 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger >> <emulb...@googlemail.com> wrote: >>> 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. >> >> The thread-safety argument is more than enough for me. >> >> *If* all requests state was stored on the request, you're correct - >> there wouldn't be a need for a class-based view to be instantiated per >> request. However, at that point, you're not really using a class -- >> you're using a collection of methods that share a sub-module >> namespace. >> > > Not really. The big win from a class-based view is not being able to > store state, you can do that with local variables, it's being able to > override parts of the behavior without needing to rewrite the entire > view, or add 101 parameters.
I'm in agreement that this is the gain from class-based views. However, as soon as you show someone an instance of a class, they're going to look for the instance attributes -- that's just how classes work everywhere else in the world. Unless you can propose a mechanism for physically preventing people from assigning instance attributes to the class, I simply don't buy that documentation saying "don't do that" will be sufficient to avoid confusion. >>> So is this purely about preventing users from shooting themselves in the >>> foot? (hyperbole: Will there be protection from globals in django 1.4?) >> >> "Don't use global variables" is advice that is contained in any >> first-year CS textbook. >> >> "Don't use instance variables on a class" isn't advice you're going to >> see printed very often. Yet that would be the advice that would be >> *required* in order to use stateless class-based views in the way you >> describe. >> >> Objects have state. I don't think it's at all unreasonable to suggest >> that a instances of a class based view should be able to have state. >> And even if we documented the fact that they can't have state, I'm >> willing to *guarantee* that people will *try* to make them stateful. >> >> So - we can: >> * spend a bunch of time writing infrastructure to prevent people from >> putting stateful variables onto their class-based views >> * spend a bunch of time answering the same question over and over >> again on django-users >> * pick an infrastructure that lets people use classes the way they expect. >> > > We don't have that documentation for the admin. Either we need it, or > our users are a little bit smarter than we're giving them credit. Or a third option -- the use case for the admin is different. ModelAdmin is a pret-a-porter interface to a high level piece of functionality with a couple of clearly documented extension points. The API that ModelAdmin exposes doesn't provide any encouragement to store state on the ModelAdmin instance itself. The fact that ModelAdmin isn't thread safe in that way isn't documented, because it's simply never been an issue -- the interface it provides doesn't encourage you to do things that would cause the thread non-safety to be exposed. This contrasts directly with Class-based views: a low-level view construction kit. Although the interface for the generic class-based views will be well defined in the same way as the admin, the base View class isn't. Best practice may well be to avoid state variables, but I don't think any amount of documentation will stop people from using them. Yours, Russ Magee %-) -- 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.
