Шаблонизация в PHP

Шаблонизация — это работа по интеграции готовой, статичной вёрстки на сайт.

Ведя работу над сайтом, написанном на PHP, мы разрабатываем логику, которая управляет представлением. Логика — это PHP-сценарии, где происходит объявление переменных, функций, использование массивов и циклов, получение и обработка информации.

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

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

Что такое «шаблон» и при чём здесь рыба?

Шаблон — это готовая вёрстка страницы или блока, которая состоит только из оформления, и не содержит никакого контента (полезной информации).

Шаблон по своей сути — это обычный PHP-сценарий, который на 90% состоит из HTML-кода и только на 10% из PHP-конструкций. Основная задача программиста в процессе работы над сайтом — это превратить статичные HTML-страницы в динамичные PHP-шаблоны, которые будут использоваться для показа итоговых страниц.

Но если статичная вёрстка страниц не содержит динамического контента, то что будет на его месте до начала внедрения этих страниц? Когда дизайнер или верстальщик хотят показать, как будет выглядеть страница на сайте, то вместо реального контента используется так называемая рыба. Рыба — это заполнитель. Бессмысленный текст, который используется в вёрстке, чтобы показать, как будет выглядеть страница, наполненная контентом.

Проблемы типичного процесса вёрстки

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

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

Общие фрагменты страниц сайта

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

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

Сбор страницы из частей

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

Потренируйтесь собирать страницы из фрагментов, выполнив это задание.

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

В разговоре о шаблонизации очень важно придерживаться определённых терминов, чтобы всегда было понимание, о чём идёт речь. Договоримся использовать следующую терминологию:

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

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

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

Содержимое шаблона

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

Данные в шаблоне

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

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

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

Логика шаблона

В шаблоне должна находиться только несложная логика. Иными словами, шаблоны не содержат «тяжёлого» PHP-кода, а только простые конструкции.

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

Функция-шаблонизатор

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

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

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

Пример использования

Посмотрим на примере, как это всё работает. Начнём с того, что определим три шаблона: лейаут, шаблон страницы и какой-нибудь блок.

Напоминаю, что в лейаут выносим общий HTML-код.

       
Дневник погоды
 
    

Теперь очередь за шаблоном страницы: [main.php]

 
Последние записи
 Добавить новую   
 

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

А вот и шаблон блока для показа одной записи: [inc/item.php]

Так выглядели три шаблона. Все они примут участие в формировании итоговой страницы. Соберёт эти шаблоны и выведет страницу на экран наш сценарий — index.php:

 $items_list]); // окончательный HTML код $layout_content = renderTemplate('layout.php', ['content' => $page_content, 'title' => 'Дневник наблюдений за погодой']); // вывод на экран итоговой страницы print($layout_content); 

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Источник

Ещё раз о шаблонах

Рано или поздно девелоперу, создающему сайты статусом выше «сайт-визитка», приходится сталкиваться с таким понятием как «шаблоны» или «шаблонизация» визуального представления (не шаблоны проектирования). Что это такое? Механизм шаблонов позволяет отделять визуальное представление веб-приложения (по-скольку работаю только с веб-приложениями, то и рассуждать буду в этом контексте) от бизнес-логики таким образом, чтобы при изменении, например, внутренней логики попутно не приходилось переделывать всю html-верстку. На этом поприще уже давно существует несколько отдельно стоящих флагманских решений, позволяющих создавать довольно гибкие приложения в плане разделения труда дизайнеров-верстальщиков и программистов, а также предотвращать запутанность кода в больших приложениях. Описывать все их нет смысла. Это уже сделано до меня и не один раз. Помимо этого, почти каждая CMS и фрэймворк имеет собственные решения для отделения логики приложения от логики представления.

Конечно, когда речь идет о проекте в десятки тысяч строк кода, когда у заказчика есть возможность нанять и программиста, и верстальщика, то и функционал шаблонов будет только пользой для всех участников проекта. Но когда разработчик в простецкий сайт в 3 страницы начинает втуливать Smarty, это ИМХО уже перебор. В таких случаях я люблю вспоминать выражение Джорджа Шлоснейгла из его замечательной книги «Профессиональное программирование на PHP» – «попытка убить муху молтком».

Действительно, встраивая все тот же Smarty в весьма простой по функционалу сайт, разработчик попросту тратит время. А время, как известно, — деньги. Да и в большинстве случаев заказчику безразлично на каком шаблонизаторе будет работать его сайт. Заказчик больше печется о затраченном времени.

Что же делать, если сайт не «визитка», но и не второй Amazon? Лично я считаю, что в этом случае оптимальное решение проблемы — воспользоваться своей самописной системой шаблонов, весь функционал которой, заточен только для решения узкого круга задач, необходимых для текущего ресурса. Впоследствии вы, возможно, выведите свою «формулу» универсального шаблонизатора с неким минимальным набором функций, расширяемую по мере необходимости в отдельно взятом проекте.

Может показаться, что автор сей статьи весьма скептически относится к Smarty и другим шаблонизаторам. Это не так. Я довольно долго работал с проектом, в котором роль шаблонизатора выполнял все тот же Smarty. И хочу заметить, мне весьма понравилось использование этой системы шаблонов в контексте обширного по функционалу проекта.

• Возможность назначать переменные шаблону
• Отдельное пространство имен переменных для отдельно взятого html-шаблона
• Возможность использования одного шаблона для общего каркаса страницы во избежание повторения конструкций вида require ‘header.tpl’;… require ‘footer.tpl’; в каждом файле

• Проект является интернет-магазином или социальным сообществом
• 10-20 типов страниц. Подчеркиваю — НЕ страниц, а типов страниц. Например: страница описания товара. Т.е. html-шаблон для этого типа страниц будет один, но самих страниц, когда каталог заполнится контентом будет много

Рассмотрим простейший класс, который состоит всего из трех методов.

_tmpl = $filename; > public function assign($name, $value) < $this->_vars[$name] = $value; > public function render() < if (count($this->_vars) > 0) < extract($this->_vars); > $tmplPath ; if (file_exists($tmplPath)) < require $tmplPath; >else < throw new Exception("Шаблон _tmpl> не найден"); > > > 

Давайте рассмотрим пример с применением этого класса. Создадим следующую структуру каталогов:

/wwwroot
|
— /classes
| — Template.php
— /templates
| — Main.tpl
| — Catalog.tpl
| — Product.tpl
| — Index.tpl
| — 404.tpl
|— index.php

 
Страница описания продукта № 

 
Это главная страница сайта
 

/** * Буферизация вывода. * Все, что будет выводиться echo-м или print-ом, будет попадать в буфер, а не в браузер пользователю. */ ob_start(); // Подключаем шаблонизатор require dirname(__FILE__).'/classes/Template.php'; // Производим проверку маршрутизации и включаем необходимые шаблоны // Если не один из шаблонов не найден, отправляем клиенту код ошибки и показываем шаблон 404.tpl // Если маршрут не задан, выводим главную страницу if (isset($_GET['route']) && $_GET['route'] == 'catalog') < $tmpl = new Template('Catalog'); $tmpl->assign('ID', $_GET['ID']); $tmpl->render(); > else if ($_GET['route']) && $_GET['route'] == 'product') < $tmpl = new Template('Catalog'); $tmpl->assign('ID', $_GET['ID']); $tmpl->render(); > else if (!isset($_GET['route'])) < $tmpl = new Template('Index'); $tmpl->render(); > else < header("HTTP/1.0 404 Not Found"); $tmpl = new Template('404'); $tmpl->render(); > // Получаем содержимое буфера $content = ob_get_clean(); // Инициализируем шаблон каркаса страницы и выводим ранее сгенерированное содержимое $tmpl = new Template('Main'); $tmpl->assign('content', $content); $tmpl->render(); 

Как видно из примера, содержимое страниц catalog и product изменяется в зависимости от значения $_GET[‘ID’]. Т.о. мы получили два типа шаблонов и неограниченное количество страниц, генерируемых приложением из этих шаблонов.

Вывод: не стремитесь во всех проектах, которыми вы занимаетесь, использовать навороченные библиотеки шаблонизаторов, предоставляющих большое обилие всевозможных инструментов, в большинстве случаев не используемых в должном объеме. Лучше всего написать свое решение, которое поможет сэкономить время, системные ресурсы, а главное — нервы останутся в порядке.

Источник