我创建了一个简单的自定义上下文处理器,每个请求只需要运行一次。在放入一些日志钩子后,我发现每个请求都会调用它两次。
这是文档中遗漏的已知“功能”吗?是不是跟继承树中的模板个数有关?这是1.03中的错误吗?
我创建了一个简单的自定义上下文处理器,每个请求只需要运行一次。在放入一些日志钩子后,我发现每个请求都会调用它两次。
这是文档中遗漏的已知“功能”吗?是不是跟继承树中的模板个数有关?这是1.03中的错误吗?
这不是预期的行为。上下文处理器在每次实例化 RequestContext 时执行一次)。在模板继承的情况下,相同的上下文实例被传递给父模板,因此不应该导致上下文处理器的另一个执行。您的日志记录具有误导性(请参阅@Vinay Sajip 的评论),或者您需要弄清楚代码中的哪个位置可能会在每个请求上执行额外的 RequestContext(您是使用包含标签还是其他呈现模板的自定义模板标签和实例化 RequestContext?)
编辑对不起,“包含标签”是指(在一般意义上)呈现另一个模板的某个标签,而不是任何使用包含标签装饰器的标签。一个常规的包含上下文的标签应该简单地传递现有的上下文对象,而不是实例化一个新的 RequestContext。
您可以尝试的一件事是在上下文处理器中放置一个“import pdb;pdb.set_trace()”,在 Django 开发服务器中运行代码,然后在控制台中每次上下文处理器被命中时使用 pdb 检查堆栈跟踪,看看它是从哪里调用的。
在我的情况下,使用django
debug_toolbar
. 为避免这种情况,请尝试发表评论
debug_toolbar.middleware.DebugToolbarMiddleware
我弄清楚了这个问题。如果返回原始上下文以外的字典,则似乎再次执行上下文处理器。不知道为什么,我也不能确定,因为我没有查看底层代码,但是在我更新了原始上下文并返回之后,问题就消失了。谢谢。
这是在生产网络服务器、Apache 等上发生的,还是仅仅在内置的开发服务器上发生的?我注意到有时在本地有类似的行为,但我很确定这只是运行服务器中的一个怪癖。
希望这可以帮助:
在我的情况下,问题是一个模板标签,即:来自 allauth 包的 providers_media_js。
尽量不要在上下文处理器中返回任何内容,看看问题是否仍然存在。然后尝试找出导致此问题的变量。
供将来参考——我的问题是render_to_string
视图函数内部,导致上下文处理器执行两次:
comments = render_to_string('comments.html', {'comments': comments_list}, request)
这个调用被缓存了,所以很难确定问题出在哪里。无论如何,我通过从调用中删除请求上下文来解决它render_to_string
,因为在这种特殊情况下我不需要它:
comments = render_to_string('comments.html', {'comments': comments_list})
后来我重构了代码并将render_to_string
所有内容一起删除,并将代码片段直接缓存在模板中。但是render_to_string
在视图函数内部使用是合法的(例如渲染电子邮件模板),所以这可能会导致一些问题。