On 1 December 2010 11:41, burc...@gmail.com <burc...@gmail.com> wrote: > Hi Russell, > > On Wed, Dec 1, 2010 at 4:03 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Wed, Dec 1, 2010 at 3:55 PM, Mikhail Korobov <kmik...@googlemail.com> >> wrote: >>> Just for the record: I'm with Ivan here and think that >>> >>> from django.template.response import TemplateResponse >>> def my_view(request): >>> return TemplateResponse(request, 'foo.html') >>> >>> is worse than >>> >>> from django.shortcuts import render >>> def my_view(request): >>> return render(request, 'foo.html')
I disagree. "TemplateResponse" is more explicit and readable. render() is confusing, because it doesn't actually render anything - it creates a lazy response. >>> >>> I think that the cases where user should prefer 'render' returning >>> HttpResponse over 'render' returning TemplateResponse are rare so the >>> API by itself should suggest TemplateResponse. TemplateResponse is >>> more flexible and can provide a performance benefit (the template >>> rendering can be prevented in some cases). >>> >>> I don't see much value in adding 'render' shortcut that just use >>> RequestContext after TemplateResponse is introduced - one can still >>> use render_to_response if TemplateResponse is undesired and one >>> shouldn't use such 'render' in other cases. Lots of people find render_to_response so verbose, that they are using direct_to_template() view instead. Django 1.3 deprecates that one, so it would be fair to offer those people a replacement. Forcing them at the same time into the world of lazy baked responses isn't very fair, imho. >>> >>> 'render' as alias for TemplateResponse seems fine for me: it is a >>> shortcut and it adds value by simplifying the API. >> >> I'd argue it doesn't simplify anything. It saves you a grand total of >> 10 characters (plus a couple more on import), but at the cost of the >> added complexity of having two ways of doing *exactly* the same thing. >> There is also a loss of explicitness -- there's no doubting what >> TemplateResponse will return. I agree :). >> >> On the other hand, there *is* value in adding a render() shortcut -- >> because there will be a subset of cases where a TemplateResponse isn't >> needed, but a HttpResponse with a RequestContext is. I think that subset is quite large (basicaly, I didn't found a use case for a TemplateResponse in my apps yet). >> >> Yours, >> Russ Magee %-) > > If I got it right, you want to make default shortcut render() that > would not use TemplateResponse. > But then how one will alter 3rd-party rendered responses in middleware? You can always alter the 3-rd party view to render the response a bit differently, which should be easy with class-based views now. > I suggest people use TemplateResponse by default, and making render = > TemplateResponse just to be sure of this, > and render_to_response is "just 10 more characters" or a line to make > your own render that uses RequestContext. > I think, talking about "saving few characters" is not constructive. > So I'm talking about good architecture and code beauty. Having basicly the same thing under 2 names is not code beauty, imho - but I don't think we should go this way in this discussion. > I think your will to make render=render_to_response with > RequestContext means you want people to use render_to_response by > default. I would like to doing, what I did with direct_to_template() right now. If I decide TemplateResponse is a better alternative, I'll switch to that. > But I'd like if we have a way to make template creators to use > TemplateResponse by default. That would encourage better view reusing > in django. And that means we would have render=TemplateResponse. There is not point in having render shortcut then (apart from saving 10 characters). You can just tell people to use TempateResponse. Generally, I don't like the current render() that much, 'cause it still doesn't let you render a page with status different from 200 (something simillar to http://code.djangoproject.com/ticket/9081) -- Łukasz Rekucki -- 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.
