как объединить шаблон из других обработанных шаблонов?

Question

У меня есть проект django pro1 с несколькими приложениями: app1, app2, app3 и так далее. Я хочу отобразить шаблон верхнего уровня, который содержит блоки из каждого приложения:

example_base_template.html:

[header /]
[left nav bar]{{ app1 rendered template }}[/left nav bar]
[right nav bar]{{ app2 rendered template }}[/right nav bar]
[center section]{{ app1 main functionality template }}[/center section]
[footer]{{ app3 rendered template }}{{ app4 rendered template }}[/footer]

Все эти шаблоны приложений являются динамическими, которые используют БД. Как сделать это самым правильным и элегантным способом? Или, может быть, вопрос в том, как подключить 4 разных представления к одному URL?

Answer 1

Вы можете использовать тег {% include%} . Но это не очень тебе помогает. Лучшее решение - написать собственный тег включения с необходимым шаблоном и функциональностью.

Вы не можете (простым способом) смешать несколько видов в одно. Попробуйте пометить его красивое решение Django.

Answer 2

Я сделал это, написав собственные теги шаблонов для каждого приложения, которое я хотел включить. Сначала теги моего шаблона только что вернулись в жестко закодированном HTML. Позже я обнаружил, что теги могут загружать свои фрагменты шаблона. Где-то был также фрагмент, который представлял собой общий тег с последним содержимым, который работал очень хорошо.

Answer 3

Многие многократно используемые приложения (особенно те, которые были выбраны в проекте Pinax ) служат отличным примером того, как использовать пользовательские теги шаблонов для вставки содержимого. выступление Джеймса Беннетта в DjangoCon 2008 также может помочь.

Answer 4

У нас была проблема, подобная этой, и ключом является получение правильных данных в контексте. То, что мы сделали, разбило создание данных / заполнение контекста для каждого представления на отдельную процедуру построения контекста. Исходные представления просто вызывают соответствующую подпрограмму, а затем отображают их шаблон. Составное представление вызывает каждого из создателей контекста, а затем отображает главный шаблон, который затем включает под-шаблоны.

Здесь мы столкнулись с небольшой проблемой с системой шаблонов Django. Мы кэшировали фрагменты шаблонов, и некоторые из этих фрагментов брали данные, которые были очень дорогими для генерации. Если фрагмент не был устаревшим, мы определенно не хотели делать работу. Но задержка работы до тех пор, пока мы не знали, что она нам нужна, означала, что мы теперь в шаблоне и:

• Нельзя передавать параметры в методы из шаблона.
• Метод django.template .__ init __. Variable._resolve_lookup () был прерван в том, что если вы передали вызываемый объект, он не будет вызываться! Если вы ссылаетесь на метод объекта в контексте, это прекрасно работает.

Причина, по которой требуются вызываемые элементы для работы, заключается в том, что она позволяет вам передавать карри-функцию - то есть функцию, в которой уже определены некоторые (или все) ее параметры, но , которая еще не была вызвана. Таким образом, представление (или контекстная сборка в этом случае) должно иметь возможность каррировать полностью указанную функцию (помните, что вы не можете передавать параметры в самих шаблонах), чтобы шаблон при необходимости может вызвать вызываемый объект, получить данные и мы отправимся в путь.

Мы использовали два разных подхода к этому:

• Мы использовали шаблонный тег expr с djangosnippets.org
• Мы взломали код шаблона django, чтобы заставить работать вызываемые элементы (я использовал отправленный, но еще не обработанный патч).

С тех пор как мы создали этот сайт, я узнал, что мы могли бы решить его, используя генераторы в качестве производителей данных с задержкой. Генераторы действуют как карри-функция (в которой вы можете передавать произвольные параметры для установки), но механизм шаблонов видит их как еще один итератор. Есть отличный учебник на эту тему. Примечание: генераторы не являются массивами, и вы можете использовать их только один раз, поэтому, возможно, придется изменить некоторые из ваших логик.

В следующий раз я думаю, что мы просто пойдем с шаблонами jinja2 и перестанем дурачиться с шаблонами Django.