On Sun, Oct 3, 2010 at 12:20 AM, George Sakkis <george.sak...@gmail.com> wrote: > 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.
In fairness, my position of "consensus" was based on the many previous mailing list discussions that have occurred, as well as the outcome of a couple of in-person discussions during sprints of the major players. It's clear from this revival of the discussion that this consensus wasn't as strong as I thought it was. I completely agree that we don't want to rush this. The upside is that if we *can* reach consensus, it isn't going to require a whole lot of code changes; We're arguing about how to architect the base class, but once we've got that sorted out, Ben's patch is feature complete and shouldn't be too hard to adapt to any base class along the lines of what we've been describing. > 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. I can see two problems here: * You still need to assign instance variables during construction; if you call self.foo during __init__(), you don't have a request; so this means we need to dynamically swap in a request-based __setattr__/__getattr__ as part of __call__. * The more complicated things are, the more likely they are to break in interesting and creative ways. Futzing with __getattr__/__setattr__ (especially if it's happening dynamically during class use) strikes me as the sort of thing that has the potential to backfire in really unusual ways, especially if people get comfortable with the idea that this class-based view really is just a class, and they start pushing the envelope. 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.
