Django - 为什么我应该使用render_to_response？ [英] Django - Why should I ever use the render_to_response at all?

问题描述

考虑这一点：

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

开一方面， render 更清洁，更多的是pythonic。另一方面，您使用请求作为您的第一个参数，我发现冗余和混乱。所以我开始想知道更大的差异...

On the one hand, render is cleaner and more pythonic. On the other, you use the request as your first argument which I find redundant and confusing. So I started wondering about the bigger differences...

根据文档：

render（）是与使用
context_instance参数的render_to_response（）调用相同，强制使用RequestContext。

render() is the same as a call to render_to_response() with a context_instance argument that forces the use of a RequestContext.

所以区别只在于使用RequestContext。那么RequestContext有什么重要？让我们再来看一下 docs ：

So the difference is only in using RequestContext. So what's important about RequestContext? Let's look at the docs again:

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

a special Context class [...] acts slightly differently than the normal django.template.Context. The first difference is that it takes an HttpRequest as its first argument.

好的。这几乎不重要

第二个区别是，根据您的TEMPLATE_CONTEXT_PROCESSORS，它会自动填充上下文
和几个变量
设置[...]除了这些，RequestContext总是使用
django.core.context_processors.csrf [...]它刻意硬编码
，不能被关闭TEMPLATE_CONTEXT_PROCESSORS
设置。

The second difference is that it automatically populates the context with a few variables, according to your TEMPLATE_CONTEXT_PROCESSORS setting [...] In addition to these, RequestContext always uses django.core.context_processors.csrf [...] it is deliberately hardcoded in and cannot be turned off by the TEMPLATE_CONTEXT_PROCESSORS setting.

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

So this is the important part - making sure all context processors work properly, with an emphasis on csrf. So really, to go back to my first example, these are actually the same:

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

现在，第二个例子显然更糟，整个事情看起来都很复杂。所以我的大问题是为什么要使用 render_to_response ？为什么不弃用它？

Now, The second example is obviously far worse, the whole thing seems woefully overcomplicated. So my big question is Why use render_to_response at all? Why not deprecate it?

其他的问题出在了：

1. 是否有更好的方法来执行 RequestContext 作为默认值？


2. 有没有办法避免通过请求作为参数？这是非常多余的。我发现博客帖子，显示如何使将render_to_response转换成易于使用的装饰器。我们不能做类似于 render 的事情吗？


3. 有没有想过这个问题（如果这是一个问题） ？我在未来的淘汰时间轴中看不到任何内容。我觉得特别令人困惑，考虑到 render 来自django 1.3 具体而言以解决render_to_response 的问题，而 你不应该使用 render_to_response

1. Isn't there a better way to enforce RequestContext as the default?
2. Is there a way to avoid passing request as an argument? It's terribly redundant. I found a blog post showing how to make render_to_response into an easy to use decorator. Can't we do something similar with render?
3. Is there any thought about this issue (if it is an issue at all)? I see nothing of it in the future deprecation timeline. I find it especially confusing, considering render came about with django 1.3 specifically to address the problems with render_to_response, and that everyone agrees you shouldn't use render_to_response

我知道这似乎有点偏离主题，但是'希望得到答案，这将解释为什么 render_to_response 正在停留，并且使用 render_to_response 将优先于 render （如果有的话）

I know it seems a little off-topic, but I'm hoping to get answers that will explain why render_to_response is staying around and\or examples of use-cases where using render_to_response will be preferred over render (if there are any)

推荐答案

大多数应用程序使用 render_to_response ，因为它是从一开始直到Djang的默认推荐选项o 1.3。两者共存的原因是历史性的，不屑一顾的 render_to_response 将迫使很多代码被重写，这在次要版本中是不礼貌的。不过在这个django-developer线程中他们说可以在2.0的淘汰时间表中加入。

Most of the apps use render_to_response since it was the default recommended option since the very beginning until Django 1.3. The reason for the coexistence of both is historical, deprecating render_to_response will force a lot of code to be rewritten, which is not polite in minor releases. However in this django-developer thread they say it would be possible to include in the deprecation timeline for 2.0.

以下是 Russell Keith-Magee ，Django的核心开发人员之一。 Keith-Magee回答了Jacob Kaplan-Moss发表的一个问题，另一个Django的贡献者提出了一个不赞成的问题： render_to_response ：

Here's the quote by Russell Keith-Magee, one of Django's core developers. Keith-Magee answers a question posted by Jacob Kaplan-Moss, another Django contributer who raises the question of deprecating render_to_response:

我认为我们应该废弃render_to_response（），有利于render（）。
render_to_response（）只是渲染（request = None，...），对吧？任何
的理由保持两者？除了不推荐使用的代码流失之外，没有什么特别的理由。

I think we should deprecate render_to_response() in favor of render(). render_to_response() is just render(request=None, ...), right? Any reason to keep both around? There's no particular reason to keep both around, other than the code churn that deprecation would entail.

而Keith-Magee回答： p>

And Keith-Magee answers:

这是我在2.0
计划上没有问题的弃权，但是每次使用render_to_response（）在$ b上$ b接下来的18个月/ 2版本似乎是一个极端的措施，在维护render_to_response（）不执行任何真正的努力时，在整个用户基础上执行
。

This is something that I have no problem deprecating on the 2.0 schedule, but migrating every use of render_to_response() over the next 18 months/2 releases seems like an extreme measure to enforce on the entire user base when maintaining render_to_response() doesn't take any real effort.

没人一直在讨论这个贬低，但我猜你的问题的答案是：没有技术原因，这只是他们的意图，不要强制更新所有的代码库未成年人（至少没有专业）发行。

Nobody's been discussing that deprecation, but I guess the answer for your question is: There's no technical reason, it's just their intent not to force an update on all the codebase in a minor (at least no major) release.

这篇关于Django - 为什么我应该使用render_to_response？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！