Maybe not important but makes bit harder to find in it trac :) Russ there is a typo in subject, ticket id is #6735, not 6375.
On Fri, Oct 15, 2010 at 8:11 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Fri, Oct 15, 2010 at 1:59 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote: >> I realize this is a bit late and not even the "right" discussion, bit >> I just stumbled across this and the wiki, and I feel a bit sick to my >> stomach. >> >> 1) self.request? >> >> Whatever gains come from this will be offset by loss in design. A >> method is called by a request. That is simple common sense. A method >> doesn't access a request. I'm sorry, if I'm missing something here, >> but this seems as backward as an intentional sabotage to Django would >> be. >> >> 2) "getting in the way if you do want to share a lot of code between >> GET and POST methods" >> >> For those of us not reinventing the blog, or creating content sites, >> this is an automatic disadvantage. >> >> 3) .as_view()? >> >> Nothing needs to be said about the confusing mess that is the class >> based views API. > > In fact, a great deal *has* been said. The most recent mailing list > thread about this exact topic ran to *over 100 messages*. That's the > second mailing list thread in recent memory that ran to comparable > length, and the topic has been discussed many times over the years. > > as_view() exists for a very good reason. The same goes for > self.request, and the dispatch mechanism. > > It seems to me that before you weigh into a discussion that you've > "just stumbled into", and you're concerned by what you see, you might > want to avail yourself of the opportunity reading the history that has > led us to the design that we have on the table. We're not stupid, and > the designs that exist, exist for a reason. > > We're happy to entertain design suggestions, but only if they're > enlightened by the extensive discussions that have proceeded the > implementation that we have. You're free to say "as_view() sucks", but > unless you are proposing an *specific* alternative that isn't fraught > with the problems that led us to that solution in the first place, > you're not going to get much traction. > > 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. > > -- 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.
