Django как подключить шаблон из другого приложения
Я стараюсь изо всех сил писать многоразовые приложения Django. Теперь я озадачен, как собрать их всех вместе, чтобы получить окончательный проект.
для этого я мог бы поместить поля внешнего ключа в блог, чтобы указать на фотографии. Но тогда блог не мог быть используется без приложения изображения. Также я мог бы создать третье приложение, которое отвечает за подключение обоих.
каков наилучший способ сделать это ?
EDIT: Спасибо за ваши очень хорошие ответы, но я все еще ищу более практический пример того, как решить эту проблему. Чтобы завершить мой пример: иногда было бы неплохо использовать приложение без приложения Фото. Но если я жестко закодирую зависимость, это больше невозможно. Так как насчет 3rd app объединить оба ?
введение разговор в нижней части ответа (более прямо к ответу). Я предположу, что у вас есть одно приложение для обработки текста под названием Text и одно приложение для обработки изображений под названием Pictures и третье приложение для ведения блога под названием Blog.
большая картинка
вам нужно будет учиться руководство по языку шаблонов для программистов python. Идея заключается в том, что каждая вещь находится в своем собственном приложении и что у вас есть третье приложение, которое подключается всё. Затем приложения должны предоставить свои модели и представления, как вам нравится (просто не забудьте сосредоточиться на том, что должно делать приложение), а также предоставить набор шаблонов.
как сделать теги включения
сделайте теги включения, и это действительно легко! Это напомнит вам о написании нормальных представлений.
создайте каталог templatetags в папке приложения. Также создайте __init__.py файл в этом templatetags (так что каталог становится python пакет.)
создайте файл python. Имя важно, вы будете использовать это в в шаблонах, которые будут использовать ваше приложение. Например, если вызвать файл picturestags.py , вы будете называть
во всех шаблонах, которые будут использовать его.
сначала в файл добавьте некоторые политики, о которых вам не нужно много думать, просто включите это прежде всего:
затем добавьте теги, определив функции с тем же именем, что и ваш тег. Я позвоню это display_picture в Примере, и он будет принимать один аргумент url. Функция должна создать словарь,который будет использоваться в шаблоне. Мой пример просто отобразит изображение, на которое указывает url.
создайте шаблоны/изображения пути в вашем приложении и создайте файл display_picture.html внутри содержит:
как вы, вероятно, понимаете, @register делает этот тег, что внутри словаря display_picture возвращает то, что вы можно использовать в display_picture.формат html. Очень похоже на ваши обычные функции просмотра.
в конце концов вы получите эти файлы:
это все, что вам нужно добавить в приложение фотографию. Чтобы использовать это в своем блоге, вам нужно добавить фотографии в INSTALLED_APPS. Затем в шаблонах, где вам нужно использовать свой собственный недавно испеченный тег, сначала загрузите его: тогда просто добавьте тег как это:
результаты
обратите внимание, что только блог имеет зависимости, и это зависимости, которые он должен иметь (без блога текст и картинки. но картинки могут жить и без текста). Внешний вид и размещение должны и могут контролироваться CSS и DIV/SPAN-тегами. Таким образом, вы можете взять свое приложение для фотографий и дать его кому-то, кто понятия не имеет о текстовом приложении и использовать его, отображая изображения по-разному, вероятно, даже не касаясь кода!
включения теги-это единственное, что я знаю, так как я только вчера узнал. Я думаю, что это удобство, предоставляемое Django, чтобы сделать жизнь простой. На на странице документации есть намного больше (включая то, как сделать "реальные" теги сложным способом без "ярлыков"). Поэтому, если вы найдете этот метод ограниченным, прочитайте документацию. у него есть много примеров. В нем также обсуждается, как сделать фильтры, simple_tags, соображения потока и другие продвинутые вещи.
введение
у меня была именно эта проблема, поскольку вы и я также хотели чего-то другого, чем ответы, которые я читал (я не говорю, что ответы были плохими, они помогли мне многому научиться и дали мне понимание, но я хотел, чтобы это я пишу сейчас). Мне удалось выяснить что-то, что не очень очевидно, благодаря вашему вопросу и, безусловно, благодаря переполнению стека, так что это мой вклад даже в вопрос полугодовой давности, который, вероятно, заброшен (может помочь гуглеру или двум)!
я также получил много вдохновения от Google Tech Talk Многоразовые Приложения. В конце (43 минуты) он упоминает некоторые хорошие примеры, такие как django-пометка что он говорит модель для того, как писать многоразовые приложения. Это дало мне идею для всего этого, потому что именно так django-tagging решает эту самую проблему, которую мы имели/имеем.
подумайте об этом так же, как вы использовали бы любое стороннее приложение в своем проекте. "Повторно использовать "не означает"без зависимостей". Напротив, вам будет сложно найти приложение, которое не имеет хотя бы одной зависимости, даже если оно зависит только от библиотек Django или core Python. (В то время как основные библиотеки Python обычно рассматриваются как "безопасные" зависимости, т. е. все будут иметь его, вещи иногда меняются между версиями Python, поэтому вы все еще блокируете свое приложение в конкретный момент времени).
цель повторного использования такая же, как и у DRY: вы не хотите писать один и тот же код снова и снова. В результате имеет смысл вырваться из функциональности, такой как приложение picture, потому что вы можете использовать его снова и снова в других приложениях и проектах, но ваше приложение picture будет иметь зависимости, и другие пакеты будут зависеть от него, пока нет круговых зависимостей, вы хороши (круговая зависимость будет означать, что у вас нет фактически разделили функциональность).
Это хороший вопрос, и что-то я нахожу довольно трудно управлять также. Но-вы представляете, что эти приложения будут выпущены публично, или вы используете их только сами? Если вы не выпускаете, я бы не волновался слишком об этом.
другое дело, что зависимости хорошо иметь. Приложение pictures в вашем примере звучит как хороший кандидат на "многоразовое" приложение. Он прост, делает одно, и может быть использован другим приложения.
приложение для блога, с другой стороны, обычно должно потреблять другие приложения, такие как приложение для изображений или приложение для тегов. Я нахожу эту зависимость прекрасной. Вы можете попытаться немного абстрагировать его, просто связавшись с медиа-ресурсом, который был помещен туда вашим приложением picture.
Это все просто немного здравого смысла. Можете ли вы сделать свои приложения тонкими? Если да, то попробуйте создать их, чтобы их можно было использовать повторно. Но не бойтесь принимать зависимости, когда они имеют смысл. Также пробовать разрешить точки расширения, чтобы вы могли потенциально поменять зависимости на другие. Прямой внешний ключ здесь не поможет, но, возможно, что-то вроде сигналов или Restful APIs может.
я новичок в Django и я столкнулся с той же проблемой. Позорно, как много шума о многоразовых приложениях в сообществе Django, но ни одной авторитетной ссылки на то, как их подключить в проект без жестких зависимостей.
я работал над новым проектом Django, и я хотел настроить свои модели, чтобы избежать жесткого кодирования как можно больше. Это шаблон, который я использовал.
планировка
модели приложения
base.py : этот модуль реализует только "причину существования" этого приложения в абстрактных классах. Правила таковы:
этот модуль обычно импортируется только из core app. Обычно он ничего не импортирует из других приложений в том же проекте.
исключение к вышеуказанному правилу когда " причина для существование предполагает существование другого приложения. Например, group приложение предполагает, что есть user приложение где-то. В этом случае способ связать их:
, а затем с помощью параметров.AUTH_USER_MODEL для ссылки на user модель
используйте этот шаблон для всех приложений, а не только user app. Например, вы также должны сделать
если вы используете вышеуказанный шаблон, только предполагайте функциональность предоставлено base.py другое приложение с которой вы связаны. Не предполагайте функциональность сложных конкретных классов (я буду обсуждать, где поставить конкретные классы в ближайшее время)
конечно, импорт из django, сторонних приложений и пакетов python разрешен.
убедитесь, что предположения, которые вы делаете в base.py любого приложения является твердым камнем и не будет многое изменится в будущем. Хороший пример - django-registration Джеймс Беннетт. Его старое приложение, но его привлекательность не ослабла, потому что он сделал твердые предположения. Поскольку хорошие многоразовые приложения делают одну вещь хорошо, нетрудно найти этот набор предположений.
basemixins.py : этот модуль должен реализовывать вилки для конкретных моделей этого приложения. "Вилка" к модели M-это любая модель, содержащая внешний ключ к модели M. Например:
BaseOwnedByGroup является "вилкой" для group модель. Правила здесь следующие: так же, как base.py`
- при определении "подключается" в basemixins.py , только предполагают функциональность, предоставляемую base.py .
- импорт только из core , django, сторонние приложения и пакеты python.
mixins.py : этот модуль должен использоваться для двух целей
чтобы определить сложные "вилки", который предполагает функциональность сложных конкретных классов, но не отношения с другими приложениями. Сложный штепсельные вилки должны в идеале наследовать один из "базовых разъемов", определенных в basemixins.py .
чтобы определить модели mixin (которые не являются "вилками"), которые могут использоваться конкретными классами этого приложения.
concrete.py : этот модуль должен использоваться для определения (вы догадались) конкретных классов этих приложений и для настройки отношений с другими приложениями. Короче говоря, этот модуль предполагает ваш проект и все функциональность, которую вы хотите предоставить в он.
взаимоотношения с другими приложениями должны быть настроены следующим образом:
создать one to one или many to one отношения с моделью M приложения another_app сделайте следующее:
создать many to many отношения, рекомендуемый способ-использовать through модель. Наследовать правильный плагин в through модель точно так же (как мы сделали в ConcreteGroup модель)
В своем проекте вы можете захотеть переопределить шаблон в другом приложении Django, будь то стороннее приложение или приложение contrib, например django.contrib.admin . Вы можете поместить переопределения шаблонов в каталог шаблонов вашего проекта или в каталог шаблонов приложения.
Если у вас есть каталоги шаблонов приложений и проектов, которые содержат переопределения, загрузчик шаблонов Django по умолчанию сначала попытается загрузить шаблон из каталога уровня проекта. Другими словами, DIRS ищется раньше APP_DIRS .
Переопределение из каталога шаблонов проекта ¶
Сначала мы исследуем заменяющие шаблоны, создавая заменяющие шаблоны в каталоге шаблонов вашего проекта.
Допустим, вы пытаетесь переопределить шаблоны для стороннего приложения с именем blog , которое предоставляет шаблоны blog/post.html и blog/list.html . Соответствующие настройки для вашего проекта будут выглядеть так:
Параметр TEMPLATES и BASE_DIR уже будет существовать, если вы создали свой проект с использованием шаблона проекта по умолчанию. Параметр, который необходимо изменить, - это DIRS .
Эти настройки предполагают, что у вас есть templates каталог в корне вашего проекта. Чтобы переопределить шаблоны для blog приложения, создайте папку в templates каталоге и добавьте файлы шаблонов в эту папку:
Загрузчик шаблонов сначала ищет шаблоны в DIRS каталоге. Когда мнения в blog приложении попросить blog/post.html и blog/list.html шаблоны, загрузчик будет возвращать только что созданные файлы.
Переопределение из каталога шаблонов приложения ¶
Поскольку вы переопределяете шаблоны, расположенные за пределами одного из приложений вашего проекта, чаще используется первый метод и помещает переопределения шаблонов в папку шаблонов проекта. Однако, если вы предпочитаете, можно также поместить переопределения в каталог шаблонов приложения.
Во-первых, убедитесь, что настройки вашего шаблона проверяются в каталогах приложений:
Если вы хотите поместить переопределения шаблона в вызываемое приложение, myapp а шаблоны для переопределения имеют имена blog/list.html и blog/post.html , тогда ваша структура каталогов будет выглядеть так:
Если APP_DIRS установлено значение True , загрузчик шаблонов будет искать шаблоны в каталоге шаблонов приложения.
Расширение переопределенного шаблона ¶
Настроив загрузчики шаблонов, вы можете расширить шаблон с помощью тега шаблона, в то же время переопределив его. Это может позволить вам вносить небольшие изменения без необходимости повторной реализации всего шаблона.
В своем проекте вы можете захотеть переопределить шаблон в другом приложении Django, будь то стороннее приложение или приложение contrib, такое как django.contrib.admin . Вы можете поместить переопределения шаблонов либо в каталог шаблонов вашего проекта, либо в каталог шаблонов приложения.
Если у вас есть каталоги шаблонов приложений и проектов, которые оба содержат переопределения, загрузчик шаблонов Django по умолчанию будет пытаться сначала загрузить шаблон из каталога на уровне проекта. Другими словами, DIRS будет искаться раньше, чем APP_DIRS .
Переопределение из каталога шаблонов проекта¶
Сначала мы изучим переопределение шаблонов путем создания заменяющих шаблонов в каталоге шаблонов вашего проекта.
Допустим, вы пытаетесь переопределить шаблоны для стороннего приложения под названием blog , которое предоставляет шаблоны blog/post.html и blog/list.html . Соответствующие настройки для вашего проекта будут выглядеть следующим образом:
Параметры TEMPLATES и BASE_DIR уже существуют, если вы создали проект, используя шаблон проекта по умолчанию. Настройка, которую необходимо изменить, это DIRS .
Эти настройки предполагают, что у вас есть каталог templates в корне вашего проекта. Чтобы переопределить шаблоны для приложения blog , создайте папку в каталоге templates и добавьте файлы шаблонов в эту папку:
Загрузчик шаблонов сначала ищет шаблоны в каталоге DIRS . Когда представления в приложении blog запросят шаблоны blog/post.html и blog/list.html , загрузчик вернет только что созданные файлы.
Переопределение из каталога шаблонов приложения¶
Поскольку вы переопределяете шаблоны, расположенные вне одного из приложений вашего проекта, чаще всего используется первый метод, и переопределения шаблонов размещаются в папке templates проекта. Однако при желании можно поместить переопределения в каталог шаблонов приложения.
Во-первых, убедитесь, что настройки шаблона проверяются в каталогах приложений:
Если вы хотите поместить переопределения шаблонов в приложение под названием myapp , а переопределяемые шаблоны называются blog/list.html и blog/post.html , то ваша структура каталогов будет выглядеть следующим образом:
Если для APP_DIRS установлено значение True , загрузчик шаблонов будет искать в каталоге шаблонов приложения и находить шаблоны.
На этом занятии мы с вами познакомимся с третьей компонентой паттерна проектирования MTV – шаблонами (templates). Что это такое? Вот смотрите, если мы откроем наш проект и запустим тестовый веб-сервер, то на главной странице увидим отображение одной короткой строчки. Как вы понимаете, полноценная HTML-страница содержит гораздо больше информации, в том числе, заголовок и подключаемые статические файлы. Конечно, если решать эту задачу «в лоб», то можно было бы написать в функции представления что-то вроде:
Но, представьте, во что тогда превратится программа! Ее будет сложно читать, исправлять и, кроме того, изменение HTML-страницы повлечет изменение и самого приложения. Это полное безумие! Поэтому неудивительно, что все это выносится за пределы приложения и организуется в виде шаблонов HTML-страниц. И сейчас мы с вами узнаем, как в Django организованы шаблоны, где их хранить и как подключать.
Первое, что нужно знать, это как представляются шаблоны в Django. Работа с ними очень похожа на работу шаблонизатора Jinja, о котором я создавал серию занятий:
Далее, я буду полагать, что вы владеете этим материалом. Если это не так, то рекомендую с ним ознакомиться, прежде, чем двигаться дальше. Также рекомендую посмотреть русскоязычную документацию по шаблонам Django:
Итак, предположим, что в качестве главной страницы мы бы хотели отобразить некоторый шаблон с именем index.html. Для этого, вначале нам нужно импортировать встроенный в Django шаблонизатор. По умолчанию в файле women/views.py это уже сделано вот такой строчкой:
Здесь первый параметр обязательно должен быть ссылкой request, а второй – путь к файлу шаблона. И здесь мы подошли ко второму важному вопросу: где должны располагаться шаблоны текущего приложения Women? По умолчанию, Django ищет шаблоны в подкаталоге templates нашего приложения. Создадим его. По идее, мы можем располагать здесь наши файлы шаблонов и все должно работать. Но есть один важный нюанс. При сборке всего проекта все шаблоны от всех приложений помещаются в единую папку templates проекта и если окажется в разных приложениях два одинаковых файла (с одинаковыми именами), то возникнет неопределенность (будет взят первый попавшийся файл). Чтобы этого не происходило, в templates приложения принято создавать еще один подкаталог с именем приложения. В нашем случае – women. И уже в него помещать файлы шаблонов. Тогда при сборке этот подкаталог целиком перенесется в каталог templates проекта и коллизий имен файлов не произойдет.
Итак, создадим в подкаталоге templates/women файл index.html с содержимым:
Это будет наш первый простейший шаблон, представляющий главную страницу сайта. И, далее, в функции render укажем путь к этому шаблону:
Все, при обновлении главной страницы в браузере, мы увидим этот шаблон. Как видите все достаточно просто и удобно.
Обратите внимание, для корректного отображения кириллицы все шаблоны рекомендуется сохранять в кодировке utf-8. Тем более, что сам Python, начиная с версии 3, по умолчанию использует юникод.
Давайте для примера добавим еще одну страницу и один шаблон на наш сайт – страницу «О сайте». Пропишем следующие пути (в women/urls.py):
И функцию about в файле women/views.py:
Добавим шаблон about.html:
И при переходе по адресу:
этот шаблон будет отображен.
Передача шаблонам параметров
Я много раз произносил слово «шаблон», но что оно означает? Если посмотреть на файлы index.html или about.html, то это просто текст, который загружается и отдается браузеру по соответствующему запросу. Все так, но в этих же файлах можно прописать конструкции для отображения информации, например, из БД. Давайте для начала сделаем так, чтобы на каждой странице был свой заголовок, переданный ей через параметр title. Это можно сделать так. В файлах index.html и about.html укажем переменную title:
А в функциях представлений передать параметр title соответствующему шаблону:
Все, теперь вместо title будет подставлена строка «Главная страница» или «О сайте» и отображаться на соответствующей странице. Удобно, правда? Вот в этом и есть роль шаблонов: они описывают структуру страницы, а ее наполнение происходит динамически в самой программе.
Можно выполнять передачу и более сложных данных, например, списков. Предположим, главное меню сайта определено через список:
А, затем, в функциях представления, мы можем передать его как параметр:
Для отображения этого списка в шаблонах, очевидно нужно перебрать в цикле его элементы и сформировать отдельные пункты:
Все, если теперь перейти на сайт и отобразить, например, главную страницу, то увидим этот список в виде HTML-тегов.
Создание базового шаблона (наследование шаблонов)
Наверное, многие из вас заметили, что у нас получилось два одинаковых шаблона и для них нарушается принцип программирования:
DRY – don’t repeat yourself (не повторяйся).
Чтобы устранить этот недостаток, обычно, создается базовый шаблон представления страниц на сайте, а уже потом он расширяется шаблонами отдельных страниц. Давайте сформируем шаблон базовой страницы в виде файла base.html со следующим содержимым:
А в дочерних расширим этот базовый шаблон:
- для index.html:
- для about.html:
Все, теперь никакого дублирования в наших шаблонах нет и мы можем достаточно просто описывать отдельные страницы сайта, просто меняя базовый шаблон base.html.
Отображение списка статей
Теперь, когда мы в целом разобрались, что из себя представляют шаблоны, давайте выполним чтение данных из таблицы women и отобразим список статей на главной странице сайта. Для этого в модуле women/views.py выполним импорт моделей:
А, затем, в функции представления index прочитаем записи из таблицы Women и передадим коллекцию шаблону:
Видите, как просто это делается! Нам даже не нужно беспокоиться о подключении к БД. Фреймворк Django все эти операции берет на себя. Все что нам нужно – это выбрать нужные записи из таблицы и передать их в шаблон. В самом шаблоне index.html переберем эти записи и отобразим в виде списка на странице:
Все, возвращаясь на главную страницу нашего сайта, увидим список записей из БД. На мой взгляд, проще не придумаешь. Django этим и хорош. У него богатый функционал, но достаточно простой в использовании. Поэтому, даже начинающий веб-программист сможет с его помощью создавать грамотные сайты. На этом мы завершим первое знакомство с шаблонами. На последующих занятиях углубимся в эту тему и затронем фильтры и подключение статических файлов.
Видео по теме
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
Django предоставляет удобный и мощный API для загрузки шаблонов с диска с целью удаления избыточности в вызовах подгрузки шаблонов и в самих шаблонах.
Для использования этого API сначала требуется указать среде разработки где располагаются шаблоны. Это делать надо в файле конфигурации проекта — settings.py , как мы показывали в прошлой главе, когда рассказывали о параметре ROOT_URLCONF .
Если вы следуете книге, откройте ваш settings.py и найдите параметр TEMPLATE_DIRS . По умолчанию, он равен пустому кортежу, содержащему несколько автоматически сгенерированных комментариев:
Этот параметр указывает механизму шаблонной системы Django пути, по которым следует искать шаблоны. Укажите требуемый каталог, в котором вы будете хранить шаблоны, например так:
Надо отметить несколько моментов:
Вы можете указать любой каталог, который доступен на чтение пользователю, от которого работает ваш веб сервер. Если вы не можете придумать такое место, мы рекомендуем создать каталог templates в каталоге вашего проекта (т.е. в каталоге mysite , который вы создали в главе « Начинаем » ).
Если ваш параметр TEMPLATE_DIRS содержит только один каталог, не забудьте запятую в конце строки с каталогом шаблонов!
Дело в том, что Python требует наличия запятой в одноэлементном кортеже, чтобы отличать его от обычного выражения окружённого скобками. На этом обычно попадаются новички.
Если вы используете Windows, включите букву диска и используйте Unix-стиль с прямыми слэшами вместо обратных, вот так:
Проще всего использовать абсолютные пути (т.е. пути до каталогов, которые начинаются от корня файловой системы). Если вы желаете быть более гибким и независимым в данном вопросе, вы можете воспользоваться тем, что файлы настроек в Django — это всего лишь код на языке Python и содержимое TEMPLATE_DIRS можно изменять динамически, например:
Этот пример использует « волшебную » переменную __file__ , которая автоматически заменяется именем файла модуля Python, в котором располагается данный код. Она получает имя каталога, в котором содержится settings.py ( os.path.dirname ), соединяет его с templates кроссплатформенным способом ( os.path.join ) и затем проверяет, что используются только прямые слеши, а обратных нет (в случае Windows).
Работая с динамическим Python кодом в файле настроек, следует отметить, что очень важно избегать ошибок в этом коде. Если вы сделаете синтаксическую ошибку или ошибку, которая возникнет во время исполнения кода, ваш сайт не будет работать.
После установки TEMPLATE_DIRS , следующим шагом будет изменение кода представления для использования функциональности Django для загрузки шаблонов, вместо указания путей к шаблонам. Возвращаясь к нашему представлению current_datetime , давайте изменим его следующим образом:
В данном примере, мы использовали функцию django.template.loader.get_template() вместо ручной загрузки шаблона из файловой системы. Функция get_template() принимает имя шаблона в качестве аргумента, производит поиск такого шаблона на файловой системе, открывает этот файл и возвращает скомпилированный объект Template .
В данном примере наш шаблон имеет имя current_datetime.html , но в расширении .html нет ничего особенного. Вы можете давать вашим шаблонам любое расширение или вообще не использовать его.
Для того, чтобы определить расположение шаблонов на файловой системе, get_template() использует информацию из TEMPLATE_DIRS и переданное имя шаблона. Например, если параметр TEMPLATE_DIRS содержит '/home/django/mysite/templates' , функция get_template() будет искать шаблон по пути /home/django/mysite/templates/current_datetime.html .
Эта страница с ошибкой похожа на такую же, которую мы рассматривали в главе « Представления и привязки URL » , только одна вещь тут новая — отладочная информация: секция « Template-loader postmortem » . Эта информация неоценима при отладке ошибок загрузки шаблона.
Далее, создадим файл /home/django/templates/current_datetime.html в вашем каталоге с шаблонами, с помощью кода:
Обновите страницу в вашем браузере и вы увидите результат обработки шаблона.
render_to_response()
Речь идёт о функции render_to_response() , которая определена в модуле django.shortcuts . Чаще всего вы будете использовать render_to_response() вместо вышеописанных действий, кроме случая когда ваш работодатель оценивает ваш труд по количеству написанных строк кода.
Ниже представлен старый знакомый пример current_datetime , использующий функцию render_to_response() :
Какая разница! Пройдёмся по изменениям в коде:
Первым аргументом функции render_to_response() должно быть имя используемого шаблона. Вторым аргументом, если он есть, должен быть словарь, используемый при создании контекста для этого шаблона. Если вы не предоставите второй аргумент, функция будет использовать пустой словарь.
Подкаталоги в get_template()
Может стать неудобно хранить все шаблоны в одном каталоге. Вам может понадобиться хранить шаблоны в подкаталогах вашего каталога шаблонов, это нормально. Действительно, мы рекомендуем делать так. Более продвинутые особенности Django (такие как общая система представлений, которая будет описана в главе « Генерация данных, отличных от HTML » ) ожидают такое расположение шаблонов по умолчанию.
Хранение шаблонов в подкаталогах несложное занятие. В вашем вызове get_template() , просто включите имя подкаталога и слэш перед именем шаблона, вот так:
Так как render_to_response() является небольшой обёрткой к get_template() , вы можете делать то же самое и с первым аргументом функции render_to_response() .
Нет ограничений на глубину дерева подкаталогов. Используйте столько сколько нужно.
Замечание
Пользователи Windows должны использовать прямой слэш ( / ) вместо обратного ( \ ). Функция get_template() ожидает прямые слэши в имени файла с шаблоном.
Шаблонный тег include
После того как мы описали механизм загрузки шаблонов, мы можем рассказать о встроенном шаблонном теге, который использует его: . Этот тег позволяет вам подключать содержимое другого шаблона. Аргументом тега является путь к подключаемому шаблону. Имя шаблона может быть представлено как переменной, так и строкой, заключённой в двойные или одинарные кавычки. Если вы используете один и тот же код в нескольких шаблонах, рассмотрите возможность использования тега , чтобы исключить дублирование кода.
Следующий пример дважды подключает содержимое шаблона nav.html . Строки примера эквивалентны, несмотря на разницу используемых кавычек:
Следующий пример показывает как следует подключать содержимое шаблона includes/nav.html :
Следующий пример подключает содержимое шаблона, имя которого содержится в переменной template_name :
Подобно функции get_template() , имя файла для шаблона определяется с использованием каталога для шаблонов из параметра конфигурации TEMPLATE_DIRS .
Подключенные шаблоны обрабатываются в контексте шаблона, который их подключил. Например, рассмотрим два шаблона:
При обработке шаблона mypage.html с контекстом, в котором определена переменная current_section , тогда переменная будет доступна в « подключенном » шаблоне, как вы могли ожидать.
Если подключаемый шаблон не существует, Django выполнит одно действие из нижеприведённых:
Если параметр конфигурации DEBUG имеет значение True , вы увидите исключение TemplateDoesNotExist на странице с ошибкой.
Если параметр конфигурации DEBUG имеет значение False , вы не увидите никакой ошибки, просто в месте подключаемого шаблона ничего не отобразится.
| Пред. | Уровень выше | След. |
| Использование шаблонов в представлениях | Начало | Наследование шаблонов |
4 комментария | Оставьте комментарий
А как передать в render_to_response() несколько переменных?
Второй параметр - словарь.
Глупый вопрос, а что делать, если нет параметров, а только файл шаблона? render_to_response требует параметр.
Ответ на Nule
Глупый вопрос, а что делать, если нет параметров, а только файл шаблона? render_to_response требует параметр.
Читайте также: