Полагаю, он хочет поощрять повторное использование шаблона по наследству (используя extends), а не по составу. Возможно, это означает, что если вы не можете организовать свои шаблоны таким образом, догматическое мнение заключается в том, что ваш сайт организован плохо. (Например, если вы повторно используете навигационное меню, не должно ли оно всегда быть в одном и том же месте в структуре страницы? Почему каждая отдельная страница должна решать, где ее разместить?)
Кстати, использование include мало поможет вам оставаться СУХИМЫМ, потому что любой контекст, который требует включенный шаблон, должен передаваться из всех представлений, которые его используют.
В отличие от этого, использование пользовательского тега шаблона включения позволяет вам выполнять произвольный код Python в точке, где включен тег, а не в виде (или помещать его в модель просто для создания проще получить доступ к шаблону).
В качестве тривиального примера я хотел показать список аватаров пользователей. Используя include, это выглядит так:
{% 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, ни функцию представления.
При этом, я думаю, в некоторых ситуациях вы неизбежно располагаете схожими данными в контексте нескольких шаблонов, вам не нужно делать с этим ничего особенного, вы просто хотите отобразить некоторые из его атрибутов, чтобы вы не Я не хочу писать функцию, чтобы она работала.
Например, я написал приложение для блога (а у кого нет?), В котором было два типа представления архива: базовое последовательное, X-записей на страницу и ежемесячное представление архива. Оба шаблона, очевидно, имели список постов в своем контексте, оба использовали один и тот же фрагмент сводного шаблона, чтобы показать заголовок и выдержку из каждого поста, но каждый шаблон представил их в несколько ином контексте. Поэтому я использовал:
{# 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, как упражнение для (без сомнения, скучающего) читателя.
Уф! Кажется разумным придумать способ сделать то же самое, используя как композицию, так и наследование, но последний просто наклоняется назад, чтобы соответствовать той догме, о которой говорил Джейкоб Каплан-Мосс?
Просто посмотрев видео (да, все 1 час 5 минут, просто чтобы я мог закончить отвечать на этот вопрос), я не думаю, что Джейкоб был бы чрезвычайно обеспокоен. Это звучало как неординарный комментарий, возможно, ссылка на то, какую технику вы должны рассмотреть в первую очередь.