Django: расширяется или включайте?
У моего друга и меня есть маленький спор. В моем текущем Django Project я создал файл под названием menu.html, который будет содержать набор ссылок, настроенных и отформатированных в список. Вместо вручную жесткого кодирования меню в каждую страницу я в настоящее время включаю меню с помощью следующего кода Django/Python:
{% include 'menu.html' %}
Однако мой друг предполагает, что это - неправильный способ сделать это. Он сказал, что я должен использовать, расширяется вместо, включают и затем определяют содержание, что-то вроде этого:
{% extend 'menu.html' %}
{% block content %}
The rest of my content here.
{% endblock %}
Это - немного дополнительного кода. Это действительно имеет значение, который я использую? Я предпочел бы использовать первого.
3 ответа
(его друг)
На самом деле я имел в виду определение base.html , чтобы вы могли наследовать базовый шаблон, соответствующий несколько общих разделов, этот включает в себя doctype, элемент html определяет 3 блока для контента и навигации и дополнительную область для переопределения / вставки элементов скрипта / ссылки в заголовке.
<!doctype>
<html>
<head>
{%block extrahead %} {%endblock %}
</head>
{%block nav %}
<nav>
<ul>
<li>home</li>
</ul>
</nav>
<div id="content">
{% endblock %}
{%block content %}
{% endblock %}
</div>
</html>
Затем вы можете определить homepage.html :
{% extends "base.html" %}
{% block content %}
homepage content
{% endblock %}
homepage.html тогда будет иметь навигацию, потому что он расширяет base.html .
Да, это важно. Во-первых, extends может встречаться только в самой первой строке файла. Во-вторых, include подталкивает и выталкивает объект контекста в стек разрешения, что означает, что значение, созданное в контексте во время включения, выйдет за пределы области видимости при возврате.
Мое правило: создавайте файлы шаблонов base.html , которые определяют общую структуру вашего сайта, и используйте обильное количество {% block foo%} вокруг критических областей.Затем все другие ваши шаблоны расширяют базу (или что-то, что само расширяет базу), и вы заменяете эти блоки по мере необходимости.
include , с другой стороны, хорош для инкапсуляции вещей, которые вам могут понадобиться, в более чем одном месте, возможно, даже на одной странице.
Обновление:
Я использую свою собственную библиотеку template_tags так долго, что забываю, что язык шаблонов Django все еще имеет серьезные пробелы в функциональности. Рассматриваемый здесь тег взят из раннего фрагмента кода django под названием expr , который я сильно отредактировал и расширил. Вы можете сказать, например, {% expr 'Fred' как name%} (или любое допустимое выражение Python), и он сохранит результат в слоте 'name' в текущем контексте. . Если это происходит во включенном шаблоне , значение name будет выскакивать при выходе из файла шаблона.
Вы можете добиться этого с помощью тега {% with%} , но expr дает мне гораздо большую гибкость, включая выполнение произвольно сложных вызовов. Первоначально это возникло, когда нужно было создавать сложные кэшированные объекты, которые требовали дорогостоящих взаимодействий с СУБД, которые не могли быть выполнены в представлении, их нужно было вызывать в самом шаблоне.
Напишите мне (в моем профиле), если вам нужно разобраться в этом подробнее.
В этом случае размещение меню в base.html и расширение от него кажется более разумным.
, включая , отлично подходит для разделения сложного шаблона и повторного использования этих фрагментов.
Допустим, вы используете один и тот же стиль списка в разных местах сайта, но отправляете ему другой набор запросов. пока вы называете наборы запросов одинаково, вам нужно написать код шаблона только один раз.
Здесь я использую разные шаблоны для нормальных и ajax-запросов. Но использование include позволяет мне повторно использовать большинство частей в обоих шаблонах