我在试着理解上下文和上下文处理器的概念。
uplii1fm1#
当你使用Django模板时,它被编译一次(并且只编译一次)并存储以备将来使用,作为一种优化。模板可以有双花括号中的变量名,例如{{ myvar1 }}和{{ myvar2 }}。上下文是一个字典,变量名作为键,变量值作为值。因此,如果上面模板的上下文如下所示:{myvar1: 101, myvar2: 102},当你把这个上下文传递给模板的呈现方法时,在你的模板中,{{ myvar1 }}会被101替换,{{ myvar2 }}会被102替换。这是一个简单的例子,但是实际上Context对象是呈现模板的 context。至于ContextProcessor,这是一个稍微高级的概念。你可以在你的settings.py文件中列出一些上下文处理器,它们接收一个HttpRequest对象并返回一个字典(类似于上面的Context对象)。上下文处理器返回的字典(上下文)被Django合并到你(用户)传递的上下文中。上下文处理器的一个用例是当你总是想在你的模板中插入某些变量时(例如用户的位置可能是候选)。与其编写代码将它插入每个视图,你可以简单地为它编写一个上下文处理器,并将它添加到settings.py中的TEMPLATE_CONTEXT_PROCESSORS设置。希望这是有意义的。谢谢你参加这门课!
{{ myvar1 }}
{{ myvar2 }}
{myvar1: 101, myvar2: 102}
101
102
settings.py
HttpRequest
TEMPLATE_CONTEXT_PROCESSORS
vawmfj5a2#
上下文是传递给模板的变量名-〉变量值Map。上下文处理器允许您指定在每个上下文中自动设置的多个变量,而不必在每个**render()**调用中指定变量。
h7appiyu3#
Context在官方文档中描述得相当不错。简而言之:1.在日常使用中,大部分是间接使用,因为helper函数会为您构建Context1.参见1:只有在使用低级API时才需要它1.不,上下文处理器是一个接受请求并返回变量字典的函数,这些变量字典随后可用于使用RequestContext呈现的所有模板,例如:
Context
RequestContext
def get_stuff_from_session(request): return {'stuff': request.session['stuff']}
3条答案
按热度按时间uplii1fm1#
当你使用Django模板时,它被编译一次(并且只编译一次)并存储以备将来使用,作为一种优化。模板可以有双花括号中的变量名,例如
{{ myvar1 }}
和{{ myvar2 }}
。上下文是一个字典,变量名作为键,变量值作为值。因此,如果上面模板的上下文如下所示:
{myvar1: 101, myvar2: 102}
,当你把这个上下文传递给模板的呈现方法时,在你的模板中,{{ myvar1 }}
会被101
替换,{{ myvar2 }}
会被102
替换。这是一个简单的例子,但是实际上Context对象是呈现模板的 context。至于ContextProcessor,这是一个稍微高级的概念。你可以在你的
settings.py
文件中列出一些上下文处理器,它们接收一个HttpRequest
对象并返回一个字典(类似于上面的Context对象)。上下文处理器返回的字典(上下文)被Django合并到你(用户)传递的上下文中。上下文处理器的一个用例是当你总是想在你的模板中插入某些变量时(例如用户的位置可能是候选)。与其编写代码将它插入每个视图,你可以简单地为它编写一个上下文处理器,并将它添加到
settings.py
中的TEMPLATE_CONTEXT_PROCESSORS
设置。希望这是有意义的。谢谢你参加这门课!
vawmfj5a2#
上下文是传递给模板的变量名-〉变量值Map。
上下文处理器允许您指定在每个上下文中自动设置的多个变量,而不必在每个**render()**调用中指定变量。
h7appiyu3#
Context
在官方文档中描述得相当不错。简而言之:1.在日常使用中,大部分是间接使用,因为helper函数会为您构建
Context
1.参见1:只有在使用低级API时才需要它
1.不,上下文处理器是一个接受请求并返回变量字典的函数,这些变量字典随后可用于使用
RequestContext
呈现的所有模板,例如: