为什么django的原始作者反对include标签?

我想他希望通过继承(使用 extends )而不是通过构图。也许这意味着,如果你不能这样组织你的模板,教条的意见是,你的网站组织得很差。(例如,如果您正在重用导航菜单,它不应该总是在页面结构中的同一个位置吗?为什么每一页都要决定放在哪里?)

顺便说一下,使用 include 对保持干爽没有多大帮助,因为包含的模板所需的任何上下文都必须从使用它的所有视图中传递。

相比之下,使用自定义 inclusion template tag 允许您在包含标记的位置执行任意python代码,而不是在视图中执行(或者将其推入模型中,以便更容易在模板中访问)。

作为一个简单的例子,我想展示一个用户头像列表。使用 包括 ,看起来是这样的:

{% for user in users %}
    {% with user.gravatar_url as avatar_url %}
        {% include "foo/bar/avatar.html" %}
    {% endwith %}
{% endfor %}

使用自定义标记:

{% for user in users %}
    {% gravatar user.email %}
{% endfor %}

使用自定义包含标记意味着 Gravatar 哈希逻辑不再是 User 模型,视图函数的NOR。

这就是说,我认为在某些情况下,在多个模板的上下文中不可避免地会有相似的数据,不需要对它做任何花哨的事情,只需要显示它的一些属性,这样就不想编写函数来使其工作。

例如,我写了一个博客应用程序(谁没有呢?)它有两种类型的存档视图:基本的顺序的,每页x-posts视图和每月存档视图。显然,这两个模板在其上下文中都有一个帖子列表,它们都使用完全相同的摘要模板片段来显示每个帖子的标题和摘录,但是每个模板在稍微不同的上下文中显示了它们。所以我用:

{# in archive_index.html #}
{% extends "base.html" %}

{# some stuff specific to sequential archives here #}

{% for post in posts %}
    {% include "post_summary.html" %}
{% endfor %}

{# probably more stuff specific to sequential archives #}

还有…

{# in archive_monthly.html #}
{% extends "base.html" %}

{# some stuff specific to monthly archives here #}

{% for post in posts %}
    {% include "post_summary.html" %}
{% endfor %}

{# probably more stuff specific to monthly archives #}

在这种情况下,组合似乎比继承更有意义。事实上,一开始很难想象遗产在这里会如何运作。嗯,还是有可能的:

{# in base_archive.html #}
{% extends "base.html" %}

{% block archive_header %}{% endblock %}

{% for post in posts %}
    {% include "post_summary.html" %}
{% endfor %}

{% block archive_pagination %}{% endblock %}

现在,这两个不同的存档扩展了这一点,只需将它们独特的内容注入到块中:

{# in archive_monthly.html #}
{% extends "base_archive.html" %}

{% block archive_header %}
    <h1>Archive for {{ month }}</h1>
{% endblock %}

{% block archive_pagination %}
    {# previous/next month links here #}
{% endblock %}

我会离开想象 archive_index.html 看起来像是(毫无疑问是无聊的)读者的练习。

唷!想出一种同时使用组合和继承的方法来做同样的事情,感觉很聪明,但后者是否只是为了遵从雅各布·卡普兰·莫斯(jacob kaplan moss)提到的教条而向后弯曲?

刚刚看了视频(是的,全部1小时5分钟,只是为了我能回答完这个问题),我不认为雅各布会有太大的麻烦。听起来像是即兴的评论,也许是指你使用了哪种技术 应该 先考虑一下。