On Oct 1, 7:26 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > I've just added a summary of the last thread on class-based views [1].
Thanks for writing this up. Having missed the discussion on that thread, the summary saved me a whole lot of time. > I'd like to try and get this in for 1.3. It's a big feature, which > means it needs to be in by October 18. However, based on the state of > the patch that Ben has prepared, I think this is an achievable goal. > Lets be clear here - I don't particularly like *any* of the options on > the table so far. Before getting on topic, I'd like to note that these two paragraphs and the general lack of consensus make me a bit uneasy. I'd rather see the feature postponed to 1.4 or the October 18 date moved later than ending up with a poor solution. With the backwards compatibility policy being what it is, design mistakes become very costly. Having said that, I'm in favour of the first approach mentioned in the wiki (store state on request) and I'm surprised it doesn't seem to have any traction in this thread. The only argument against is "it's unusual to have a class where you can't store state on self" but even that can be overcome with an appropriate __setattr__/__getattr__ that access self.request.state under the hood. Unless someone tries self.__dict__[attr], it will look as if the state is stored on the view although it's actually stored in the request (or better request.state to avoid name clashes). Perhaps I am missing something but this seems to me foolproof and much cleaner than the alternatives. George -- 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.
