Django-为什么我应该完全使用render_to_response？

  • Z时代
  • 2024-01-10
  • 分类：问答

考虑一下：

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

一方面，render它更干净，更pythonic。另一方面，你将request用作第一个参数，但我觉得这很多余和令人困惑。所以我开始怀疑更大的差异…

根据文档：

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

因此，区别仅在于使用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？为什么不反对呢？

想到的其他问题：

  1. 有没有更好的方法来强制执行RequestContext默认设置？

  2. 有没有办法避免传递request为参数？这是非常多余的。我找到了一篇博客文章，展示了如何使render_to_response成为易于使用的装饰器。我们不能做类似的事情render吗？

  3. 有没有考虑这个问题（如果有问题的话）？在将来的弃用时间表中，我什么也看不到。考虑render到django 1.3 专门解决了render_to_response的问题，并且所有人都同意 你不应使用 django 1.3 ，我觉得这特别令人困惑。 render_to_response

    我知道这似乎有点题外话，但我希望能得到答案，以解释为什么render_to_response会留下来和/或用例的示例，其中使用render_to_response将优先于render（如果有）

回答：

大多数应用程序都使用render_to_response它，因为自从Django 1.3开始就一直是推荐的默认选项。两者并存的原因是历史性的，弃用render_to_response将迫使大量代码被重写，而在次要版本中这并不礼貌。但是，在这个django-developer线程中，他们说有可能将2.0的弃用时间表包括在内。

这是Django的核心开发人员之一Russell Keith-Magee的报价。Keith-Magee回答了另一位Django贡献者Jacob Kaplan-Moss提出的问题，提出了弃用问题render_to_response：

我认为我们应该弃用render_to_response（），转而使用render（）。render_to_response（）只是render（request = None，…），对吗？有什么理由让两者同时存在吗？除了弃用可能引起的代码混乱外，没有什么特别的理由可以保留两者。

而Keith-Magee回答：

在2.0计划上，我对此没有任何疑问，但是在维护render_to_response（）时，在接下来的18个月/ 2个版本中迁移render_to_response（）的每次使用似乎是对整个用户基础实施的一种极端措施。付出任何真正的努力。

没有人讨论过这种弃用，但是我想你的问题的答案是：没有技术原因，这只是他们的意图是不对次要（至少没有主要）发行版的所有代码库进行强制更新。

以上是 Django-为什么我应该完全使用render_to_response？ 的全部内容， 来源链接： utcz.com/qa/432965.html

回到顶部