Hi Russell, On Fri, Oct 16, 2009 at 8:14 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > On Fri, Oct 16, 2009 at 6:01 PM, Yuri Baburov <burc...@gmail.com> wrote: >> >> That means, >> 1) perfect render_to_response should be lazy. > > This isn't a new idea - Simon Willison has been proposing this general > idea for a while. He's been talking specifically about making template > rendering lazy, so you can use middleware or wrapper views to modify > the template or the contents of the context that is used for > rendering, right up until the response is served back to the user. > There is some working code here: > > http://code.google.com/p/django-openid/source/browse/trunk/django_openid/response.py Thanks.
Exactly this is what I wasn't able to find today. So, what's the status of this proposal? Do you think this is what a lot of people would like to see in django or not? Would you, personally, like? >> Of course there's direct_to_template. Don't know how that happened >> that it appeared instead of enhancing render_to_response... >> Can be that no one knows why it has happened so? > > Easy - direct_to_response is a generic view, not a template utility. > It's designed to be the simplest possible generic view - the view that > renders a template with some interpreted context. The internal > processing done by direct_to_response (evaluating callables, etc) is > driven entirely by its intended use case - deployment in urls.py. > > The fact that it can be used as a substitute for render_to_response is > mostly an accident of the intentionally simple contract for a view - > that it accepts a request as it's first argument, and returns a > response. > As is regularly noted on django-users and in various books, > you can easily write view functions that wrap generic views to do > pre-processing on view arguments before passing those arguments to the > generic view. Actually, I've found I always want to do _postprocessing_ for generic views :) In the place between making final dict and rendering it with template. This is why I need lazy responses. > Using direct_to_response as a replacement for > render_to_response is really just the ultimate extension of this > theory. Great! So you confirm lack of attention? ;) Why else have nobody found this implication before committing this feature? >> Well, generally, I use to think that everything related to "django >> views in general" constantly lacks devs attention. >> Like it's perfect since long time ago. Or it is just too boring topic, >> or API stability contract tied their hands, or just everyone get used >> to it... > > Part of the problem here is betrayed by your choice of phrase - that > views are "lack(ing) devs attention". The core developers aren't here > to do your bidding. We work on the issues that we see as important - > recently, that means we've been busy trying to get features like model > validation and multi-db support into trunk. You mean, you have not enough time to support faster development of Django? Ok with that, but please, admit it, don't make a secret from this. > Views might not be perfect, and they might be able to work better, but > they _work_. If you disagree, then *you* need to solve it. Remember - > Django is open source. We'll take submissions from anyone. You just > need to demonstrate to us that your ideas are sound and your > implementation is robust. I don't owe you anything. You don't owe anything to me. But I'd like you to _encourage_ Django contributors to do stuff for Django, not impersonate a contribution to Django as a kind of "prize" only for already privileged people and unpredictable "if you can attract us" behavior, like you always do. This bitchy "we might devote some time to you if you can attract us" politics keep me away from any serious time effort in direction of contribution to Django for few years. Like you don't want to allow any contribution, but it is possible to make contribution "by force" of idea superiority. Why should I try to contribute anything, if you aren't interested in my contributions? Django just doesn't have any mechanism to take decision on small enhancements, to support and to encourage them. I checked this few times already, I've seen a lot of tickets with such enhancements. Nobody cares of them. There's no person I can talk with about my contributions. There's no person currently who can tell what's wrong with my suggestion and, what's more important, how I can fix it to get it into Django, and what exactly I should do to be sure it will be included. Total irresponsibility, lack of management, the worst side of Django communism. I want a win-win model: you and me get a feature added to Django, you want it and I want it, I make a contribution, you help me to integrate my contribution. Let's work *together* on contributing to django, not putting a bitch shield ( http://www.urbandictionary.com/define.php?term=bitch+shield ) between Django and enhancements. Sorry that I concentrated on politics issues again instead of technological. But it seems I've finally found words to express what I think about the django development process. And most technological issues have been discussed since long time ago, but nothing is done! Why? I attempted to explain, why it is so. Ok, now I'll get to technological talks again. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. 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 -~----------~----~----~----~------~----~------~--~---
