为什么是“django.core.context_processors.request”默认情况下未启用？ [英] Why is "django.core.context_processors.request" not enabled by default?

问题描述

我正在解决一个问题，通过一个新的项目获取请求obj，并实现了django.core.context_processors.request在Django的vanilla安装中被评论。

I was troubleshooting a problem with obtaining the request obj with a new project and realized "django.core.context_processors.request" was commented in vanilla installs of Django.

如标题所示，为什么这个看似有用的上下文处理器默认关闭？

Like the title suggests, why would this seemingly helpful context processor be turned off by default?

• 是否是性能问题？


• 安全性是否存在问题？ >
  
• 这是多余的吗？

有些温和的搜索对我来说没有任何东西，但是我以为我会问这里。

Some mild searching has not turned up anything for me, but I thought I'd ask here.

推荐答案

这是一个很好的问题。文档说请注意，该处理器默认情况下不启用;你必须激活它。但没有解释。

This is a good question. The docs say Note that this processor is not enabled by default; you’ll have to activate it. but no explanation.

我的看法是由于django强烈的愿望将视图逻辑与

My take on it is due to django's intense desire to separate view logic from the template.

请求对象是查看逻辑构建的所有数据的网关（给定浏览器发送给我们的是X，Y，Z） - 因此允许它在模板中类似于给模板大量的控制，应该放在正常情况下的视图中。这个想法是使用细节填充模板上下文，而不是 。

The request object is the gateway to all data that view logic is built from (given what the browser sent us, do X, Y, Z) - therefore allowing it in the templates is akin to giving the template huge amounts of control which should be placed in the view under normal circumstances. The idea is to populate the template context with specifics, not everything.

删除它们只是更多的鼓励，大多数事情应该完成在视图中。如果默认情况下不需要，通常的 django.contrib 应用程序主要不依赖它。

Removing them is just some more encouragement that "most things should be done in the view". The common django.contrib apps mostly don't rely on it, if it's not required by default.

当然，这进一步证明了请求对象在模板中是不必要的，除了特殊用例。

And of course, that's further proof the request object isn't necessary in the template except for special use cases.

无论如何，这是我的想法。

That's my take, anyways.

这篇关于为什么是“django.core.context_processors.request”默认情况下未启用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！