Django呈现于

渲染发生在 . 如果你这样写 {{ foo.bar }} 从未 foo.bar 在模板中。通过(HTML)输出替换标记等由Django呈现引擎完成。

结果 这种呈现是通过HTTP响应提供给客户机的。所以响应本身不包含 呈现逻辑 ,它包含渲染的“产品”。如果你这样做 {{ SomeModel.objects.all() }} 数据库 询问,但这是 由客户管理。客户端不知道模板调用的是什么逻辑。

这也可以使应用程序更加安全,因为客户端无法访问模板本身,因此无法更改模板以获取敏感信息。当然,通过设计特定的查询输入,它仍然可以让模板返回敏感数据。

但渲染的“产品”仍然会导致 额外的 电话

但是,结果可能会导致额外的调用。例如,如果您的结果包含 <img src=""> s、 样式表链接等和其他url,浏览器通常也会开始获取它们。此外,如果定义了执行AJAX调用的JavaScript,这些调用将导致额外的HTTP请求,但这些请求不会在 致使 特定模板的时间。这些是稍后的“独立”调用,可能再次导致呈现。

一些技术呈现在

请注意,它本身并不总是这样。一些技术,如角度,在客户端完成(大部分)渲染。在这种情况下,JavaScript代码调用API,然后按照开发人员的指定“展开”HTML。因此,完全有可能调用webservice请求tweets,然后让一些JavaScript在DOM中“注入”HTML代码来相应地呈现tweets。这样做的好处是可以方便地动态更改内容(例如,在浏览器中经常更新某个产品的值)。

但是,这需要通过API(也就是可以通过HTTP请求访问的API)提供呈现的数据,并且这些调用可能需要一些额外的安全性(对于请求数据的调用,通常需要再次检查凭据)。