> From my count there are 8 people in this thread in support of the >> functionality, and 2 people against it (1 at the time of my previous >> message). >> > > The bit you're possibly missing due to the way GMail handles some replied: > this thread was a respawn of an older thread from 6 months ago. The google > group has the full thread. > > https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion > >
I'm using Google groups to interface, I'm pretty sure I've read everything, everything in that discussion you linked seems familiar. > Of course, you might just be using your 5-person consensus to establish > that it's worth going to the trouble of actually working up a patch, but it > sounded like you were under the impression that your 5-person consensus was > enough to end up with a patch in trunk, and I want to moderate your > expectations. > That is what I was doing, I was in no way expecting my patch to be accepted just because I opened a ticket - merely that I would create a patch against the current development trunk and see where it ended up. I wasn't expecting it to get anywhere without a core developer being involved, I just figured chances of getting a core developer involved and/or interested may be increased if it was a decision to be made, rather than a patch to be written. > In regards to your concerns, which mainly seem to be in regards to how >> many people would actually utilize this feature / are currently working >> around it I'm not sure how to address that. I suppose mixins are the >> solution for now then, however it does seem to me like something that >> anyone who is making extensive use of class based views will eventually >> come up against. >> > > I'm not saying that you don't have a use for this type of entry point. > What I'm saying is that you're advocating making the basic entry sequence > of class based views (and thus, the documentation and learning curve) more > complex, all to service a use case that can be achieved with subclassing. > And, in the limited subset of people that have *huge* subclassing overheads > and find themselves writing that subclassing code over and over again, that > subset can write a new base subclass or mixing that introduces the > complexity. > > What I *don't* see is a generic, across the board need that warrants > *every* user being forced to carry the overhead so that *some* users have a > convenience that can be achieved by other means. > That's fine, I was simply trying to get a discussion going and perhaps a decision from someone who is capable of making one, as that hadn't been done up until now. I'll do my best to try and convey what I'm trying to accomplish better in the future, as it seems there may have been a bit of a misunderstanding here. Cheers, Jordan > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ar_LTkZ9ZGoJ. To post to this group, send email to django-developers@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.
