在我们的一个应用程序(运行Django 1.8)中,我们倾向于通过将字典传递到render()函数的context参数并将它们作为视图的一部分返回来呈现模板。例如:
from django.views.generic import View
class HomePageView(View):
def get(self, request, *args, **kwargs):
context = {'foo': 'bar', 'foo2': 'bar2'}
return render(request, "page.html", context)
现在我开始寻找它,我看到人们使用Django" context"对象而不是字典。
from django.views.generic import View
from django.template import Context
class HomePageView(View):
def get(self, request, *args, **kwargs):
context = Context()
context['foo'] = 'bar'
context['foo2'] = 'bar2'
return render(request, "page.html", context)
文档显示这个Context对象可以用类似于字典(pop,copy,key assignment等)的方式进行交互,并且有一个flatten()方法,可以将它与字典进行比较。 https://docs.djangoproject.com/en/1.8/ref/templates/api/#playing-with-context。
我的问题是:我有没有理由想要使用Context对象而不是字典?我可以看到如果有人想要轻松访问请求变量,有人可能会发现RequestContext的子类有用,但我想我错过了上下文对象的实用程序。
答案 0 :(得分:7)
Python字典是已知键和变量值之间的映射。 Context()
类似于字典,但Context()
提供了其他功能。
因此,在渲染模板时,您需要一个上下文。这可以是django.template.Context
的实例,但Django
也带有子类django.template.RequestContext
,其行为略有不同。
render()
快捷方式会创建RequestContext
,除非它明确地传递了不同的上下文实例。
[...]
创建了 RequestContext
和context processors
来解决冗余问题。 Context processors
允许您指定在每个上下文中自动设置的多个变量,而无需在每个render()
调用中指定变量。
[...]
请注意,TEMPLATE_CONTEXT_PROCESSORS
(在设置中)中的任何上下文处理器都将在该setteings文件提供的每个模板中可用。
自定义上下文处理器可以存在于代码库中的任何位置。所有Django关心的是,context_processors
设置中的TEMPLATES
选项指向您的自定义上下文处理器,如果您直接使用context_processors
,则Engine
参数指向context_processors.py
。话虽如此,惯例是将它们保存在应用程序或项目中名为<dependency>
<groupId>org.apache.spark</groupId>
<artifactId>spark-core_2.11</artifactId>
<version>2.1.0</version>
</dependency>
<dependency>
<groupId>com.databricks</groupId>
<artifactId>spark-avro_2.10</artifactId>
<version>3.2.0</version>
</dependency>
<dependency>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>2.11.8</version>
</dependency>
<dependency>
<groupId>org.apache.spark</groupId>
<artifactId>spark-sql_2.11</artifactId>
<version>2.1.0</version>
</dependency>
的文件中。
来源:掌握Django:核心。完整的Django 1.8LTS指南