Django - 我为什么要使用render_to_response呢？

考虑一下:

return render(request, 'index.html', {..context..})
return render_to_response('index.html', {..context..})

一方面,render更清洁,更pythonic.另一方面,你使用request作为你的第一个参数,我觉得多余和混乱.所以我开始怀疑更大的差异......

根据文件:

render()与使用context_instance参数调用render_to_response()相同,后者强制使用RequestContext.

所以区别仅在于使用RequestContext.那么RequestContext有什么重要意义呢？让我们再看看文档:

一个特殊的Context类[...]与普通的django.template.Context行为略有不同.第一个区别是它需要一个HttpRequest作为它的第一个参数.

好.这根本不重要

第二个区别是它根据你的TEMPLATE_CONTEXT_PROCESSORS设置自动填充上下文中的一些变量[...]除了这些之外,RequestContext总是使用django.core.context_processors.csrf [...]它是故意硬编码的并且不能通过TEMPLATE_CONTEXT_PROCESSORS设置关闭.

所以这是重要的部分 - 确保所有上下文处理器正常工作,重点是csrf.真的,回到我的第一个例子,这些实际上是相同的:

return render(request, 'index.html', {...})
return render_to_response('index.html', {...}, context_instance=RequestContext(request))

现在,第二个例子显然要糟糕得多,整个事情似乎过于复杂.所以我的大问题是为什么要使用render_to_response？为什么不弃用呢？

想到的其他问题:

是不是有更好的方法来强制执行RequestContext默认值？

有没有办法避免request作为论点传递？这非常多余.我发现了一篇博客文章,展示了如何将render_to_response变成一个易于使用的装饰器.我们不能做类似的事render吗？

有没有想过这个问题(如果它是一个问题)？在将来的弃用时间表中我什么都看不到.我发现它特别令人困惑,考虑render到专门用于解决render_to_response问题的 django 1.3 ,并且每个人都同意 你不应该使用 render_to_response

我知道它似乎有点偏离主题,但我希望得到的答案可以解释为什么render_to_response留下来和\或用例的例子,其中使用render_to_response将优先于render(如果有的话)