Как выполняется шаблонизация в html файле

Name already in use

iu5web-fall-2021 / tutorials / lab4 / lab4_tutorial.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Методические указания по выполнению лабораторной работы №4

Команда курса благодарит Торжкова Максима Сергеевича за активное участие в подготовке данного руководства.

Для выполнения лабораторной работы потребуется PyCharm Professional
Лицензию можно получить через сайт JetBrains, указав бауманскую почту. Также django-проект можно создать руками по этому тьюториалу

File -> New Project.
В меню New Project. выбираем Django, задаем путь к проекту в Location и задаем имя нашему приложению в Application name

В папке проекта bmstu :
settings.py — настройки проекта, в проекте может быть несколько приложений
urls.py — соответствие урлам обработчиков(views).

В пакете bmstu_lab :
views — обработчики приложения

templates — папка для шаблонов (html-файлы)

Нажимаем на кнопку Run в правом меню и запускаем приложение.

При этом в консоли должен вывестись трейс-лог о запуске приложения на localhost на порту :8000

По адресу http://127.0.0.1:8000/ в браузере должна показаться стандартная страница django-приложения.

Как работать с View и Urls

После запуска сервера по пути http://127.0.0.1:8000/hello/ вы должны увидеть

Таким образом, код hello будет вызван при обращении к серверу по урлу /hello

Шаблоном является обычный текстовой файл, чаще всего html, который содержит в себе переменные и теги. Эти конструкции при отрисовке шаблона подменяются на данные, которые пользователь передает в качестве параметров шаблонизации. В конечном итоге у нас получается html-файл, который может быть показан в браузере пользователя.

Для начала будем отдавать пользователю статичную html-страницу, в ней не будет никаких конструкций шаблонизатора.

Создаем html-файл в директории ‘templates’.

Чтобы вернуть пользователю созданный файл, используйте метод render. Например данный код возвращает страницу index.html , которая была создана в папке templates.

После запуска сервера по пути http://127.0.0.1:8000/hello/ вы должны увидеть

Переменные в шаблонизации

В шаблоне переменная имеет вид: << some_variable >> . Когда шаблонизатор рендерит страницу и находит переменную, то вместо нее он подставляет результат, который вычисляется в этой переменной.

Добавим в статичную страницу переменные.

Чтобы передать значение переменной из кода:

Если значение переменной не было передано, то она будет заменена пустой строкой. В именах переменных не может быть пробелов или знаков препинания.

После запуска сервера по пути http://127.0.0.1:8000/hello/ вы должны увидеть

В качестве переменной может быть словарь, тогда к вложенным полям можно обращаться через точку.

Теги в шаблонизации

В шаблоне теги выглядят как <% tag %>. С помощью тегов можно реализовывать условия, циклы, свою логику. Большинство тегов должны закрываться: <% tag %>content

Допустим, нам нужно вывести список элементов. Для этого воспользуемся

После запуска сервера по пути http://127.0.0.1:8000/hello/ вы должны увидеть

for итерируется по списку, доступ к элементам можно получать через созданную переменную, в данном случае var .

<% if variable %>позволяет выводить содержимое блока, если значение переменной “true” (или значение существует, либо если список и он не пустой) Вместе с этим тегом можно использовать <% elif %>,

После запуска сервера по пути http://127.0.0.1:8000/hello/ вы должны увидеть

В теге if можно использовать:

• and
• or
• not
• операторы сравнения
• in (проверка что значение существует в списке)

Наследование шаблонов позволяет создать основной шаблон, который содержит общие элементы, а частные места будут переопределять наследники. Места, которые могут быть переопределены помечаются тегами

Pug — шаблонизатор и препроцессор HTML

Добавляем корневой элемент html. Пока никакой вложенности нет, поэтому без отступов. Обратите внимание, что атрибуты тегов записываются в круглых скобках. Закрывающие теги не прописываются. Они будут автоматически сгенегированы

Добавляем два основных элемента HTML-страницы — head и body. Так как они должны быть вложены в корневой элемент html, то в строке перед head ставим один отступ Tab и в строке перед body ставим один отступ Tab. Это значит что элементы head и body будут находится внутри корневого элемента html. Опять же никаких закрывающих тегов мы не прописываем

В head добавляем мета-тег кодировки документа. Атрибуты записываем в круглых скобках. Так как мета-тег кодировки должен быть внутри элемента head, то у мета-тега должен быть на один отступ Tab больше, чем у элемента head

Аналогично добавляем мета-тег для адаптивности. Если у тега несколько атрибутов, то записываем их через пробел или через запятую. Так как второй мета-тег должен быть также внутри элемента head, то у второго мета-тега также должен быть на один отступ Tab больше, чем у элемента head

Также в head добавляем тег title для названия страницы и теги link для подключения файлов стилей

Добавим первый элемент в body — тег header. У header на один отступ Tab больше, чем у body, так как он должен быть расположен внутри body

Чтобы добавить класс для header, добавляем название класса через точку после названия тега, аналогично селекторам в файлах стилей CSS

Далее добавляем div с классом container. В Pug если не указывать название тега перед названием класса, то по-умолчанию назначается тег div. Поэтому вместо записи div.container , мы просто указываем название класса как в файлах стилей CSS — .container . Так как container внутри header, то у container на один отступ Tab больше, чем у header

Далее все аналогично — добавим header__flex внутри container, добавим header__logo внутри header__flex.

Теперь мы хотим добавить второй класс для header__logo — добавляем его через точку без пробелов — .header__logo.logo

Если захотим для header__logo добавить еще идентификатор, то запись будет следующей — .header__logo.logo#logo — порядок не имеет значения, так что запись может быть и такой — #logo.header__logo.logo

Добавим logo__title c текстом. Текст записывается через пробел после названия тега или тега с классом

Добавим в header__flex еще тег nav c классом header__nav и внутри него список ul c элементами списка li, которые в свою очередь содержать ссылки a c текстом.

Каждый дочерний элемент должен иметь на один отступ Tab больше, чем родительский. Но есть еще более краткая запись, через двоеточие, которую лучше использовать только для элементов, которые содержат в себе только один дочерний элемент, например li: a(href=»») Home

Первое время рекомендую самостоятельно, пошагово, добавляя по одному элементу в index.pug, смотреть на сгенерированный index.html, чтобы для себя более подробно понять, как из синтаксиса Pug генерируется разметка HTML

Нюансы синтакcиса Pug

Частая задача — в блоке с текстом необходимо определенную часть текста выделить в теги span (strong, i и другие) или сделать ссылкой a

В Pug есть два способа это сделать.

Первый способ — использовать обычные теги HTML — открывающий и закрывающий.

Второй способ — использовать синтаксис Pug — #[tagname text] — знак решётки, затем в квадратных скобках на первом месте имя тега, на втором месте через пробел текст, который будет находится в теге

Javascript файлы подключаем, также как и остальные теги

Но если необходимо добавить javascript код прямо на странице, то используем следующий синтаксис — script. — добавляем точку после имени тега script и на следующей строке с отступом на один больше, чем у тега script пишем необходимый код

Шаблонизатор

Когда верстаем многостраничный сайт, при внесении изменений, например в header, необходимо открыть каждый *.html файл, который содержит header и внести эти изменения в каждом файле.

Чтобы решить данную проблему, выделим общий фрагмент кода в отдельный файл и подключим его в шаблон

Предположим, у нас есть макет сайта с тремя страницами, где есть общие блоки header и footer, а блок main будет на каждой странице отличаться.

Когда сверстали главную страницу, сохраним блоки header и footer в соответствующие файлы header.pug и footer.pug в отдельную папку includes (создаем там же, где лежит основной файл index.pug)

Отдельная папка includes для общих фрагментов верстки нужна для того, чтобы они не генерировались как отдельные html файлы, а только подключались в шаблоны страниц. Если сохраним их рядом с index.pug, то они будут сгенерированы, как отдельные страницы header.html и footer.html, а это некорректно.

Рядом с файлом index.pug сохраняем только те файлы, которые должны быть сгенерированы, как отдельные страницы. Об этом чуть ниже

header.pug

footer.pug

Обратите внимание, что в отдельных файлах header и footer отступы сбрасываются — основные родительские элементы header.header и footer.footer в отдельных файлах не имеют отступа. Это важно при подключении этих файлов в шаблоны.

Подключим эти файлы в index.pug. Для этого используем служебное слово include .

Так как отступы в отдельных файлах header.pug и footer.pug сброшены, то при подключении header.pug через служебное слово include следим, чтобы подключение было именно в том месте, где изначально был header.header , то есть на один отступ Tab больше, чем у body. Тоже самое и с footer.pug

Теперь на основе шаблона index.pug, в этой же папке создадим еще два шаблона — portfolio.pug и about.pug

portfolio.pug

about.pug

Теперь генерируются 3 страницы — index.html, portfolio.html и about.html

При изменении header.pug или footer.pug, эти изменения будут применены сразу на всех трёх страницах

В простом примере польза шаблонизации не ощущается в полной мере, но когда реальный проект состоит более чем из 10 страниц и более 20 общих фрагментов, в которые так или иначе в процессе верстки вносятся изменения, то польза становится намного ощутимей

Возможные проблемы и их решения

В окне командной строки, где запущен Gulp, ошибки выглядят следующим образом

На скриншоте выше выделена наиболее информативная часть, где можно видеть код ошибки (code), информация об ошибке (msg), строка с ошибкой (line), файл с ошибкой (filename)

Основная ошибка — это использование в отступах Пробелы вместо Tab. В документации сказано, что в качестве отступов можно использовать или только Пробелы или только Tab.

Решить эту проблему очень просто. В редакторе кода, в файле index.pug выделяем весь код сочетанием клавиш Ctrl+A и ищем настройку Tab size (в Sublime Text и VS Code справа внизу), нажимаем и выбираем пункт Convert Indentation to Tabs — все отступы конвентируются в Tab

Преимущества верстки с Pug

У Pug много возможностей. Мы разобрали только базовые для ускорения и упрощения процесса верстки, но можем выделить следующие преимущества

Краткий, информативный, чистый синтаксис, не нужно следить за закрывающими тегами

Разбивка верстки на отдельные фрагменты, подключение этих фрагментов в шаблоны, и изменения в общем фрагменте применяются сразу на всех страницах, где он подключен

Сгенерированна верстка является валидной (проверка W3C — Markup Validation Service)

В следующей статье познакомимся и разберем работу со вторым очень полезным инструментом для ускорения верстки и более комфортной работы со стилями — Stylus (препроцессор CSS)

Как и зачем создавать собственный шаблонизатор для DOM

Прежде чем начинать изучать шаблонизацию, давайте вспомним два базовых подхода к созданию разметки.

Перед нами два отрывка кода, которые отвечают за одинаковую разметку для списка чатов: декларативный и императивный. Так это выглядит в HTML:

Теперь создаём такое же дерево, но через DOM API в JavaScript:

HTML выглядит понятнее, чем множество однотипных вызовов DOM API. Однако есть и минус: HTML статичен — его прописывают один раз и пользуются, а если нужно описать десятки или сотни однотипных элементов на странице, придётся написать всю разметку.

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

Где-то на стыке этих двух подходов работы с DOM появляется шаблонизация. С одной стороны, она позволяет описать разметку декларативно, а с другой стороны — описать динамические данные прямо в этой разметке.

Представьте, если бы вы могли создать DOM-дерево с динамическими данными, не используя createElement и описание свойств, а например, вот так:

Такая запись читается проще, чем манипуляции с document.createElement. Здесь можно:

• ясно увидеть, где должны быть имена классов и в каких местах они динамические;
• представить, как выглядит DOM-дерево сразу, не прикидывая в голове цепочку append (добавлений) элементов друг в друга;
• рендерить куски вёрстки быстро и наглядно.

К подобному синтаксису шаблона мы и будем стремиться.

Зачем это всё?

Действительно, зачем в век React, Angular и Vue заниматься такой мелочью, как шаблонизация? Все современные фреймворки умеют динамически подставлять данные в DOM и даже больше: циклы, условные операторы, компоненты, жизненный цикл.

В конце концов, если не пользоваться фреймворками — есть уже готовые шаблонизаторы, можно же взять их?

Сколько бы ни было на рынке инструментов, какие бы возможности они ни предоставляли, фактически всё сводится к 26 буквам английского алфавита, десятку символов и идеям: паттернам программирования и проектирования, принципам построения чистой архитектуры и чистого кода, шаблонам решения типовых задач.

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

Именно поэтому написана эта статья — чтобы показать один из возможных подходов к динамическому формированию разметки.

Идея и синтаксис шаблона

Шаблонизатор — это функция, которая на вход получает некоторую разметку в виде чистого текста и контекст, а на выход даёт готовый DOM-элемент или текст, готовый к использованию в innerHTML. Под контекстом подразумевается набор информации, который подставляется вместо переменных в шаблонной строке.

Чтобы шаблонизатор мог работать, нужно придумать соглашение о синтаксисе — как описать в шаблоне места, куда должны подставляться данные из контекста. Обычно используют какие-нибудь скобки, в которые помещают идентификаторы переменных.

Скобки удваиваются, чтобы не спутать динамические данные со статическим текстом, который может быть в шаблоне. Они достаточно часто употребляются в текстах, поэтому без удвоения их легко перепутать:

Если выбрать круглые скобки в качестве маркера динамических данных и не удвоить их, непонятно, где переменная, а где просто текст в скобках.

Примем за обозначение переменных в шаблоне удвоенные фигурные скобки — такое решение достаточно распространённое. Таким образом шаблон для примера выше будет таким:

Хранение шаблона

Так как шаблон — это строка, то его можно хранить просто в строке ��

Если пойти дальше и развивать идею, окажется, что необязательно хранить строку с шаблоном именно в файле с кодом. Хранение шаблона превращается в отдельную задачу в духе «получить откуда-то шаблон», например, из тега <script>:

Значение у скрипта type отличается от text/javascript, поэтому браузер не будет пытаться обработать его как JavaScript.

Получить содержимое шаблона очень просто:

Также организовать хранение шаблона можно в файле с любым расширением и импортировать его. У популярных шаблонизаторов зафиксированы свои расширения, чтобы редакторы кода могли легко их распознавать.

Можно создать и использовать шаблоны следующим образом:

Однако для такого решения, возможно, придётся настроить ваш сборщик, чтобы он корректно импортировал подобные файлы.

Желаемый синтаксис использования

Теперь, когда мы понимаем синтаксис и метод хранения шаблона, пора подумать о том, как оживлять этот шаблон и превращать его в HTML.

Что нам предстоит сделать:

1. Подготовить шаблон (написать его в переменной, импортировать или достать из template-тега).
2. Подготовить данные для шаблона.
3. Поместить данные и шаблон в шаблонизатор.
4. Поместить в DOM разметку, полученную из шаблонизатора.

Представим, как может выглядеть третий пункт:

На самом деле API шаблонизатора может выглядеть так, как вам нравится — всё зависит от задач.

Мы остановимся на третьем варианте — const markup = new Templator(template); markup.compile(data). Это позволит единожды создать экземпляр с шаблоном и в дальнейшем вызывать его метод compile с нужными данными для получения разметки.

Возможные способы реализации

Есть много способов реализовать шаблонизатора для DOM под капотом — от самых простых до сложнейших. Рассмотрим два основных:

1. Заменить по регулярному выражению все переменные, встречающиеся в шаблоне, на данные и с помощью innerHTML поместить получившуюся разметку в DOM.
2. Написать полноценный интерпретатор шаблонов, который будет символ за символом читать шаблон, разбивать его на токены, строить синтаксическое дерево и по этому дереву собирать разметку.

Первый способ — базовый и немного «костыльный». Его опасность — в innerHTML, который нежелательно использовать в более-менее серьёзных приложениях. Второй способ — достаточно мощный: он позволяет вводить различные операторы и операции в шаблон, превращая шаблоны в язык программирования.

Сейчас мы осуществим первый способ реализации, чтобы обрести базовое понимание шаблонизации.

Реализуем шаблонизатор для DOM

Попробуем заставить работать следующий код:

Раз мы приняли решение делать шаблонизатор для DOM на классе, напишем заготовку такого класса:

Конструктор принимает шаблон в виде обычной строки, а его превращение в разметку будет скрыто в методе compile.

Proof of concept — регулярное выражение

Прежде чем писать реальный код в заготовке класса, давайте потренируемся на тестовых данных. В первую очередь нам надо научиться находить в строке шаблонную переменную и на что-то её заменять.

Мы договорились о способе записи переменных в шаблоне — << someVariable >>. Найти такие фрагменты в строке нам поможет простое регулярное выражение /\<\<(.*?)\>\>/.

Попробуем применить регулярное выражение к строке с помощью метода exec:

Итак, если совпадение в строке есть, возвращается массив, у которого во втором элементе лежит то, что нам нужно — то, что внутри фигурных скобок. Это значение мы и будем использовать, чтобы обратиться к ключу объекта-контекста: «Если exec вернул не null, заменим в шаблоне встреченную шаблонную переменную на значение из контекста».

Пробуем дальше — у нас в шаблоне наверняка может встретиться не одна переменная, а несколько.

Дело в том, что у регулярных выражений есть несколько хитростей. В нашем случае регулярное выражение находит первое совпадение и останавливает работу метода exec. Требуется два шага, чтобы заставить регулярное выражение работать со всеми совпадениями.

1. Нужно добавить ему флаг g , что значит global — искать все совпадения. Регулярное выражение с флагом g будет хранить и изменять своё состояние.
2. Регулярное выражение надо применить к строке несколько раз. Сколько точно, заранее неизвестно. В этом случае отлично подходит цикл while, а условием для него будет служить знание того, что exec возвращает null, когда совпадение не найдено.

Посмотрим на примере:

Чтобы не писать exec вручную, завернём его в цикл. Но нам нужно не просто выполнить exec, а ещё и поработать с его результатом. Для этого воспользуемся особенностью JS, когда операция присваивания возвращает присваиваемое значение:

Теперь этот цикл пройдётся по всей строке и найдёт все совпадения — то что нужно!

Пишем метод compile

Теперь, когда у нас достаточно навыков работы с регулярным выражением, нужно его применить. Алгоритм следующий:

1. находим совпадение в строке шаблона,
2. очищаем от пробелов название переменной,
3. заменяем в шаблоне все вхождения этой переменной на значение из контекста,
4. повторяем.

Интересный момент в выражении new RegExp(match[0], ‘gi’). Вы помните, что exec первым элементом массива возвращает полное совпадение из строки регулярному выражению. Здесь мы создаём из этого совпадения новое регулярное выражение, чтобы заменить все вхождения в шаблон подобной строки на настоящее значение.

Такая реализация кажется достаточной, но на самом деле нужно разобраться с парой моментов:

• Что делать, если в контексте не передано нужной переменной?
• Что делать, если в нужном ключе объекта лежит не примитив, а объект или массив?
• Что делать, если в нужном ключе объекта лежит функция?

Эти вопросы не имеют однозначного ответа и выходят за рамки статьи: у нас нет цели написать полноценный шаблонизатор — мы хотим познакомиться с принципами его построения. Однако остановимся на последнем вопросе, чтобы в будущем не наделать ошибок.

Добавляем «лёгкие» обработчики событий

Итак, если в ключе контекста встречается функция, нужно корректно её обработать. Прежде всего нужно договориться о правиле применения функций в шаблоне, на соблюдение которого мы будем полагаться.

Пусть в шаблоне переменные значения с функциями помещаются только в атрибуты on*:

Вот почему обработчик называется «лёгким» — это не настоящий addEventListener, а использование DOM API. Этот шаблон должен превратиться в следующий HTML:

Обратите внимание: в HTML это именно вызов функции со скобками в конце.

Такой способ можно довольно просто добавить в текущий шаблонизатор, чтобы не перегружать его ненужной логикой. Всё остальное будет лишним и слишком сложным в ситуации простого знакомства с шаблонизацией. А ещё этот механизм не позволяет передавать в функцию атрибут event. Минусов хватает, но начинать с чего-то надо ��

Чтобы добавить такие обработчики, нужно проверить в методе компиляции, что значение из контекста по ключу является функцией. Если это так, то требуется подставлять не просто значение, но и добавлять в конец вызов функции. Например, мы передали в контексте > для шаблона <button onclick=’<>’>, а на выходе должны получить:

Но откуда возьмётся handleClick в области видимости, где его будет вызывать Browser API? Чтобы этот HTML-элемент работал корректно, функция handleClick должна находиться в window — именно там её будет искать браузер.

Помимо добавления скобок, ещё придётся присвоить функцию из контекста в какое-то поле window. Сделаем это:

Заключение

Итак, мы изучили, что такое шаблонизация, какие вопросы стоит задавать при создании шаблонизатора и как на них можно отвечать. Реализация получилась, что называется, на коленке, но она вполне отражает ход размышлений и при этом даже работает ��

Несомненно, эту реализацию можно улучшить, но стоит ли? В приведённом случае мы всё равно подвержены уязвимости в виде innerHTML, потому что не создаём в шаблонизаторе настоящий DOM, а только оперируем строкой.

Для создания настоящего DOM надо как минимум написать настоящий парсер для языка разметки, выстроить работу с абстрактным синтаксическим деревом (AST) и создать компилятор из AST в DOM API, чтобы на выходе из шаблонизатора был честный DOM-элемент с наполнением. А ещё чтобы это всё было создано с помощью document.createElement. Но эта тема тянет на несколько статей, и если вам интересно — мы с командой курса «Мидл фронтенд-разработчик» их напишем.

Немного практики

Сделайте так, чтобы в синтаксисе шаблона можно было размещать обращения к полям объекта:

Шаблонизаторы HTML: что это и стоит ли их использовать в разработке

Шаблонизаторы HTML позволяют уменьшить время на верстку страниц сайта, так как с их помощью можно разделить ее на компоненты. Они собираются между собой по аналогии с конструктором, частично изменяются при необходимости. Плюс, заранее подготовленные шаблоны можно использовать в других своих проектах. Например, не нужно будет верстать заново меню для каждого нового сайта, а можно будет использовать шаблонное решение. Шаблонизаторы — это удобный инструмент для веб-разработчика и верстальщика, но когда стоит его использовать и стоит ли вообще?

Шаблонизаторы: зачем они нужны

Шаблонизатор — это инструмент, позволяющий разделять разметку страницы на шаблонные компоненты и использовать их в текущем или других проектах разработчика. Также есть возможность связать созданные шаблоны с базами данных, что упрощает создание интерактивных страниц. Шаблонизатор избавляет от необходимости писать по несколько раз повторяющийся код, который в любом случае будет встречаться в верстке. В большом проекте написание или даже простое копирование повторяющихся элементов занимает немало времени, которое можно было бы потратить на что-то более полезное. Если говорить о конкретных задачах, для которых используется HTML-шаблонизатор, то выделяется следующий перечень:

• создание базовой разметки блоков или всей страницы;
• возможность одним действием производить правки нескольких компонентов, которые могут находиться даже на разных страницах;
• быстро менять контент в блоках;
• добавлять, удалять, перемещать блоки на странице или между страницами сайта;
• создавать повторяющиеся компоненты, например, карточки с аннотациями статей.

Когда требуется использовать шаблонизатор

Предположим, вам требуется сверстать главную страницу интернет-магазина, которая представляет из себя каталог. В нем появляются карточки товара, имеющие одинаковую структуру, но при этом с некоторыми отличиями: фото товара, название товара, цена, возможно дополнительное выделение карточек с акциями.

Писать код для каждой карточки вручную крайне непродуктивно — он практически идентичен с кодом другой карточки. В итоге вы потратите много времени на написание однотипного кода. Копировать и вставить код уже написанной карточки будет быстрее, но тоже не всегда продуктивно — карточки хоть и имеют одинаковую структуру, могут внешне отличаться друг от друга. Подход с копированием имеет смысл в том случае, если планируется сравнительно немного карточек или их вариаций. В противном случае придется тратить много времени для внесения изменений в каждую конкретную карточку. Особенно остро эта проблема будет стоять при добавлении новых карточек.

Отчасти возникшие проблемы можно исправить с помощью правильно расставленных классов в HTML. В таком случае вы просто меняете CSS-свойства нужного класса и получаете внешние изменения необходимой карточки. Однако такой подход не будет работать, если нужно изменить саму HTML-структуру карточки, например, добавить дополнительный блок с акцией.

Разные варианты отображения карточек в одном каталоге

Также в примерах с карточками товара — если заказчик вдруг потребует изменить внешний вид и структуру всех карточек, то без использования шаблонизатора это придется делать вручную.

Рассмотренная ситуация с карточками не катастрофична, но показывает следующие проблемы:

• Нужно постоянно держать в голове контент проекта, хотя бы приблизительный. Если вернуться к сайту после перерыва или если заказчик вдруг захочет внести серьезные изменения в структуру, то будет сложно адаптироваться к ним.
• Выше вероятность возникновения ошибок на этапах разработки и внесения правок. Например, можно забыть где-то применить изменения, что приведет к появлению багов во всей верстке.
• Потребуется больше времени на верстку и внесение правок.

Шаблонизатор позволяет избежать этих проблем, так как вам изначально потребуется создать набор шаблонов, которые просто будут меняться по мере необходимости. При этом вносить изменения в каждый отдельный элемент не потребуется — все будет делаться автоматически.

Работа с HTML-шаблонизаторами

Вы можете работать как с уже существующими инструментами шаблонизации, так и разработать собственные под конкретный проект. Из-за вариативности рассмотрим общие принципы работы с HTML-шаблонами, которые будут актуальны как для сторонних инструментов, так и для собственной разработки.

Для примера представим стандартный макет, который требуется сверстать. В нем есть такие элементы как шапка и подвал. Они повторяются на всех страницах и всегда (или почти всегда) имеют одинаковый внешний вид. А вот элементы, расположенные в центральной части шаблона, могут меняться в зависимости от типа страницы. Например, на главной странице сайта там может быть каталог товаров, на странице продукта в центральной части уже располагается информация о товаре и далее по аналогии.

Иллюстрация одного из вариантов расположения подключаемых блоков

В этом примере шаблонизировать можно шапку и подвал, а контент в центральной части подключать в виде отдельного файла. В нем потребуется также указать, что данный файл должен встраиваться в уже заготовленный шаблон.

Приготовление основного шаблона

Для примера рассмотрим достаточно примитивный вариант страницы и расположения контента на ней. В HTML это будет реализовано так: