Расширение tpl в php

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

Рано или поздно девелоперу, создающему сайты статусом выше «сайт-визитка», приходится сталкиваться с таким понятием как «шаблоны» или «шаблонизация» визуального представления (не шаблоны проектирования). Что это такое? Механизм шаблонов позволяет отделять визуальное представление веб-приложения (по-скольку работаю только с веб-приложениями, то и рассуждать буду в этом контексте) от бизнес-логики таким образом, чтобы при изменении, например, внутренней логики попутно не приходилось переделывать всю 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’]. Т.о. мы получили два типа шаблонов и неограниченное количество страниц, генерируемых приложением из этих шаблонов.

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

Источник

Как использовать файлы TPL

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

Файлы tpl используются для написания в них HTML-кода, который впоследствии будет «вытащен» PHP и выведен пользователю на конкретных страницах. Например, в файле tpl может быть форма регистрации. То есть просто HTML-код обычной формы, ничего больше. В другом файле tpl может быть блок с панелью пользователя. В этой панели идёт «Приветствие пользователя» по имени, различные ссылки на редактирование профиля, а также кнопка выхода. Это всё примеры, где регулярно используются файлы tpl.

Однако, есть один очень важный нюанс. Рассмотрим поподробнее файл tpl с панелью пользователя. Я написал, что там идёт приветствие пользователя по имени. Но файл один, а пользователей очень много (следовательно, и имён много). Глупо создавать для каждого пользователя отдельный файл, где жёстко прописано его имя. Поэтому в файлах tpl используются специальные элементы — шаблонизаторы. Они записываются примерно в таком виде: . Давайте приведу пример файла tpl, где используется шаблонизатор (пусть файл называется user_panel.tpl):

Как видите, никаких html>, head> и body> здесь нет. Только тот HTML-код, который отвечает за панель пользователя.

Теперь напишем PHP-код, который этот tpl-файл обрабатывает:

$username = «Пётр»; //Разумеется, это имя Вы должны сначала откуда-то взять, например, из базы данных
$user_panel = file_get_contents(«user_panel.tpl»);
$user_panel = str_replace(«», $username, $user_panel);
echo $user_panel;
?>

Как видите, всё очень и очень легко. Мы здесь получили содержимое файла user_panel.tpl, а затем с помощью функции PHP str_replace() заменили на конкретное имя пользователя.

function myfunction() < $template_path = '/templates/template.tpl'; $data = array( 'variable' =>'Значение', 'variable2' => 'Значение 2', ); $html = get_html($template_path, $data); echo $html; >

function get_html($template_path, $data) < foreach ($data as $key =>$value) < $$key = $value; >ob_start(); require($template_path); $html = ob_get_clean(); return $html; >