Всеобъемлющая история шаблонов
Автор: Дмитрий Лебедев
Источник: detail.phpclub.net
Иногда хочется отвлечься от текущей рутины кодирования и от
небольших проблем, которым посвящается место в статьях на
"деталях". Окинуть взглядом то, что делаешь долгое время.
Итак, моё видение подходов к основной задаче
php-программирования — генерации веб-страниц. Частично
тему эту я уже затрагивал по частям — статьи про класс
шаблонов и про XML вы можете найти в архиве. Теперь хотелось
бы свести всё это воедино и сделать что-то монументальное.
Первая часть.
1. Истоки php
С чего, собственно начался php для большинства из нас? С
вставок скрипта в HTML-страницы. К примеру, собственный
каталог ссылок. Страница со ссылками из определённой
рубрики:
<?php
$connection = mysql_connect("localhost", "user", "pass");
mysql_select_db("my_database");
$result = mysql_query("SELECT title FROM rubrika WHERE id=". intval($id));
if (mysql_error())
echo mysql_error();
else {
echo "<h2>". mysql_result($result, 0). "</h2>";
mysql_free_result($result);
$result = mysql_query("SELECT id, title, ratio, description, site_date FROM site
WHERE rubrika=". intval($id). " ORDER BY ratio DESC, site_date DESC, title");
if (mysql_error())
echo mysql_error();
else
while ($row = mysql_fetch_assoc($result))
echo "<b><a href=\"/redirect.php?id={$row[id]}\">{$row[title]}<br>
{$row[description]}<br><font size=\"-1\">Записано:
{$row[site_date]}, рейтинг: {$row[ratio]}
";
}
?>
Просто и незатейливо, но главное, что этот код работает.
Сложности начинаются, если попробовать написать название
рубрики в заголовке страницы. Для этого придётся создать
вставку php внутри тега <title>, перенести туда код,
выполняющий первый запрос (выборка имени рубрики), сохранять
результат запроса в переменную, которую затем выводить в теле
страницы.
Следующее осложнение — попытка работать с cookies и
выдавать их в зависимости от того, какие рубрики посещает
пользователь. Чтобы лучше представить это: пусть мы решили,
что на наш хоумпейдж пойдут толпы посетителей, и для
потенциальных рекламодателей мы делаем баннерный движок с
таргетингом. Скажем, пользователь, посетивший рубрики
рок-музыка и музыкальные инструменты, на следующей странице
увидит баннер с рекламой магазина электрогитар.
В таком случае нам придётся сделать вставку php-кода в
самом начале файла и передвинуть туда проверку наличия
рубрики, ведь куки можно выдавать только до выдачи первого
байта документа.
Конечно, вы скажете, что это можно легко сделать при
помощи механизма пользовательских сессий, что проще с точки
зрения выдачи контента и безопаснее, потому что пользователь
может вручную менять содержимое кук. Да, это так, но во-первых
здесь представляется видение новичка программирования,
делающего свою домашнюю страничку, во-вторых речь идёт о
далёком прошлом — виртуально мы с вами находимся в 1998
году.
Не сильно облегчает жизнь и вывод одинаковых блоков HTML- и
php-кода в подключаемые файлы. Описанная выше задача —
построить простой каталог ссылок с рубриками — пожалуй,
верхний предел возможностей данного подхода. При выполнении
более сложных задач очень велик риск столкнуться с большими
трудозатратами.
2. Усложнение кода
Логичным развитием предыдущего подхода является полный
переход на php в том смысле, что все страницы представляют
собой php-код — в начале файла стоит открывающий тег
"<?php", и дальше php-код не прерывается. Весь вывод
делается через echo (print). Такой код, вроде бы, выглядит
логичнее. Пример: страница подписки на новые ссылки в
каталоге. В форме предлагается выбрать, на какие рубрики
подписывается пользователь.
<?php
include "db-connect.inc";
include "login-check.inc";
if (!$logged_in) {
header ("Location: /register.php");
exit();
}
include "page-header.inc";
print("<h2> class="club_article_small_caption">Новости для клиентов</h2>
<table cellpadding=\"4\" cellspacing=\"0\" border=\"0\">");
$result = mysql_query("SELECT id, title, announce, news_date FROM news ORDER BY
news_date DESC LIMIT 10");
if (mysql_error())
print(mysql_error());
else
while ($row = mysql_fetch_assoc($result))
print("<tr><td>{$row[news_date]}");
if ($row["news_date"] > date("Y-m-d", time() - 3600*24*14))
print("<font color=\"#cc0000\">new!</font>");
print("</td><td>
<a href=\"read.php?id={$row[id]}\"><b>{$row[title]}</b></a>
<br>{$row[announce]}</td></tr>");
print("</table>");
include "page-footer.inc";
?>
Этот код уже очень сложно читать, даже если добавить к нему
комментарии. Конечно, можно "упростить" его, например, убрав
вывод анонса в функцию:
<?php
...
else
while ($row = mysql_fetch_assoc($result))
print_announce($row);
...
?>
Но это нисколько не упрощает работу, и час расплаты
обязательно наступит: возникнет необходимость переделать
дизайн сайта. Дизайнер править такое просто откажется. Только
тот, кто написал такой код, сможет в нём разобраться и
заменить старый HTML на новый. Если этот человек уже не
работает над проектом, то проект придётся переписывать почти с
нуля или же он умрёт, превратившись в памятник человеческой
недальновидности.
Другой вариант развития подхода смешанного HTML и php. У
php есть такое свойство как advanced-escaping.
Он позволяет внутри языковых конструкций выводить обычный
HTML-код:
<?php
include "db-connect.inc";
include "login-check.inc";
if (!$logged_in) {
header ("Location: /register.php");
exit();
}
include "page-header.inc";
?><h2 class="club_article_small_caption">Новости для клиентов</h2>
<table cellpadding="4" cellspacing="0" border="0"><?php
$result = mysql_query("SELECT id, title, announce, news_date FROM news
ORDER BY news_date DESC LIMIT 10");
if (mysql_error())
print(mysql_error());
else
while ($row = mysql_fetch_assoc($result)) {
?><tr><td><?=$row["news_date"]?><?php
if ($row["news_date"] > date("Y-m-d", time() - 3600*24*14)) {
?><font color="#cc0000">new!</font><?php
}
?></td><td> <a href="read.php?id=<?=$row["id"]?>">
<b><?=$row["title"]?></b></a>
<br><?=$row["announce"]?></td></tr><?php
}
?></table><php
include "page-footer.inc";
?>
Верстальщик или дизайнер, открыв этот файл в HomeSite,
увидят HTML-разметку с подсветкой и вполне смогут
редактировать оформление страниц. В простых сайтах такой метод
вполне пригоден. В сложных — ни к чёрту не годится.
3. Переворот
С выходом PHP 3.0... Кстати, не мешало бы восстановить
хронологию, раз уж речь идёт о всеобъемлющей истории. Итак,
хронология, которую удалось восстановить при помощи архива
листа рассылки php
announce и страницы
из веб-архива:
??.08.1997 PHP 3.0 Beta1
06.06.1998 PHP 3.0 Release
19.07.1999 PHP 4.0 Beta1
22.05.2000 PHP 4.0 Release
10.12.2001 PHP 4.1 Release
22.04.2002 PHP 4.2 Release
10.10.2002 PHP 4.3.0pre1 (pre1 — это не бета, но ещё не Release Candidate)
...Так вот, с выходом PHP 3.0 появился инструментарий для
применения нового подхода в php-программировании —
буферизации страниц в скриптах. (Важно заметить, что это
совсем не та буферизация,
которая есть сейчас.)
Со временем задачи построения сайтов усложнялись, php
использовался всё шире, сайты становились всё "динамичнее".
Чем больше сайт, тем проблематичнее сделать всё на
подключаемых файлах в смешанном php и HTML. Вполне логично
следующим шагом расширения php стала обработка HTML-страницы в
памяти скрипта и выдача её пользователю целиком или по частям.
Реализовать данных подход помогла худо-бедно реализованная
в PHP3 поддержка (ну хорошо, эмуляция)
объектно-ориентированного программирования. Были созданы классы шаблонов, которые позволяли легко оперировать
шаблоном страницы и данными, которые в него должны быть
внесены.
Это расширяло возможности программ, но одновременно
требовало больше системных ресурсов. Сегодня можно сказать,
что выгоды от применения такого подхода перекрыли затраты
системных ресурсов, однако ещё года два-три назад много людей
считало, что держать весь документ в памяти —
непозволительная роскошь для веб-программирования.
Итак, образно говоря, произошёл переворот в технологии:
если раньше PHP прятался в HTML-коде и робко добавлял свою
информацию, то теперь он вышел на первое место и держит весь
HTML в своих лапах.
4. Чем плохи самопальные
классы шаблонов
Спустя полгода я решил кое-что изменить в планах.
Морализаторства на тему плохости самопальных классов не будет.
Они хороши. Пользуйтесь ими, и прибудет с вами то, что вам
нужно! Только учитывайте, что вам будут мешать некоторые
обстоятельства.
Первое. Если класс писался специально, это значит, что он
несколько оторван от жизни. Пусть за классом стоит большой
опыт разработок, всё равно он делался в тепличных условиях.
Получившаяся технология будет иметь свои специфические условия
использования, под которые придётся подгонять будущие
разработки, либо переделывать класс.
Второе. Класс, который синтезируется из наработок в разных
проектах, тоже требует изменений - чем глобальнее он, тем
больше.
Итак, свои собственные классы делать можно (классы
шаблонов, насколько я знаю, очень многие используют свои
собственные). Если вы идёте дедуктивным методом, строя класс
из оценки того, что понадобится, есть небольшая вероятность,
что получится что-то гениальное. И большая вероятность, что
получится не совсем то, что нужно. Можно применить индукцию -
тогда после большой и долгой работы вы гарантированно получите
то, что работает, но не обязательно гениальное.
Плохость самоделок, которую я упоминал в предыдущих частях,
заключается в первом случае в очень большой вероятности
получить что попало, работающее не так, как вам мечталось,
требующее к себе особого подхода и много кодирования. Во
втором случае вы можете долго упорно работать и получить то,
что уже было кем-то сделано и опубликовано до вас.
Что касается сравнения технологий, то главный вопрос -
уместность. Очень простой сайт можно делать на подключаемых
файлах и не думать о классах и движках. Сайт посложнее лучше
делать на шаблонах. Если сложность возрастает и на одной
странице многое зависит от разных условий - меню навигации в
зависимости от статуса и т.д. - лучше подумать о связке
XML&XSLT.
Пример: форум phpBB. В нём нельзя поменять оформление
полностью, как вам хочется, потому что очень много элементов
оформления находятся не в шаблонах, а в php-коде. Всякие формы
для входа, меню управления для вошедшего пользователя и т.п. -
вставляются в страницу через php-код, а не как вложенный
шаблон. Cамое популярное решение - не всегда самое лучшее.
Дмитрий Котеров так комментирует опыт изучения phpBB:
написав класс шаблона, многие, будучи полны энтузиазма,
начинают пихать всё под этот класс. Идея такого класса состоит
в том, чтобы разделить код и оформление, но авторы phpBB
наоборот перемешали их насколько это было возможно.
Но на мой взгляд, даже при нормальной реализации этого
подхода (класса шаблона) код получился бы громоздкий, файлов с
шаблонами было бы очень много. В последнее время прихожу к
выводу, что на классах шаблонов в принципе нельзя толком
отделить php-код от данных и оформления. Со сменой дизайна
сайта на таком движке обязательно придётся копаться в
php-скриптах, и делать это будет не дизайнер, а вы.
Ещё пример - "Регистр" Спектатора.
Под заказ я бы писал это на XML&XSLT, но "Регистр" писался
для широкой аудитории, поэтому, естественно, такие "высокие"
технологии отвергаются с самого начала.
На этом проповедь окончена, продолжается обзор
технологий.
Перед продолжением истории — дополнение. Упущенный
мною важный момент.
Ещё один способ вывода данных и составления текстовых
строк — "Heredoc
string quoting" (cсылку на него после выхода первой части
прислал BOLK). Поддержка
его появилась с выходом PHP4.
<?php
$str = <<<EOD
Пример текста в нескольких строках
созданного при помощи синтаксиса heredoc.
EOD;
// Более сложный пример с переменными.
class foo
{
var $foo;
var $bar;
function foo()
{
$this->foo = 'Foo';
$this->bar = array('Bar1', 'Bar2', 'Bar3');
}
}
$foo = new foo();
$name = 'МоёИмя';
echo <<<EOT
Меня зовут "$name". Я печатаю немного $foo->foo.
А теперь я печатаю ещё и {$foo->bar[1]}.
Здесь должна появиться заглавная латинская 'A': \x41
EOT;
?>
Выводит пользователю «Меня зовут "МоёИмя". Я печатаю
немного Foo. А теперь я печатаю ещё и Bar2. Здесь должна
появиться заглавная латинская 'A': A».
По-моему, весьма удобный синтаксис. Однако широкого
распространения он (ещё или уже?) не получил, в "дикой
природе" мне таковой наблюдать не приходилось.
4.1 Классы шаблонов
Как уже было сказано, вышедший в 1998 году PHP3 поддерживал
некоторое подобие ООП. Это позволило создавать объекты, при
помощи которых манипулировать шаблонами и данными, которые в
них направляются, очень удобно. Намного удобнее, чем
обрабатывая данные в области глобальных переменных процедурным
подходом.
Здесь речь идёт, конечно, о шаблонах с блоками. Вставить
в текстовый шаблон выбранные переменные вполне можно без
создания класса.
Пример работы с таким классом с сайта
FastTemplate. Шаблоны (каждый — отдельный файл):
-- main.tpl --
<html>
<head><title>{TITLE}</title>
</head>
<body>
{MAIN}
</body>
</html>
-- table.tpl --
<table>
{ROWS}
</table>
-- row.tpl --
<tr>
<td>{NUMBER}</td>
<td>{BIG_NUMBER}</td>
</tr>
Программный код:
<?php
/* START */
include("class.FastTemplate.php3");
$tpl = new FastTemplate("/path/to/templates");
$tpl->define( array( main => "main.tpl",
table => "table.tpl",
row => "row.tpl" ));
$tpl->assign(TITLE, "FastTemplate Test");
for ($n=1; $n <= 3; $n++)
{
$Number = $n;
$BigNum = $n*10;
$tpl->assign(array(
NUMBER => $Number,
BIG_NUMBER => $BigNum ));
$tpl->parse(ROWS,".row");
}
$tpl->parse(MAIN, array("table","main"));
Header("Content-type: text/plain");
$tpl->FastPrint();
exit;
?>
Вывод:
<html>
<head><title>FastTemplate Test</title>
</head>
<body>
<table>
<tr>
<td>1</td>
<td>10</td>
</tr>
<tr>
<td>2</td>
<td>20</td>
</tr>
<tr>
<td>3</td>
<td>30</td>
</tr>
</table>
</body>
</html>
Конструкция весьма неудобная. Блоки здесь реализованы путём
многократной вставки в переменную подчинённого шаблона. Вот
другой пример: класс HTML_Template_IT из библиотеки PEAR.
<table border>
<tr>
<td colspan=2>
__global__
<p>
(hidden and automatically added)
</td>
</tr>
<tr>
<td>block1</td>
<td>
<table border>
<tr>
<td colspan=2>block2</td>
</tr>
<tr>
<td>inner1</td>
<td>inner2</td>
</tr>
</table>
</td>
</tr>
</table>
В документации написано, что нет необходимости указывать в
шаблоне, какой блок является дочерним от какого. Класс это сам
поймёт.
В документации к этому классу написано, что он знает, что
inner1 — дочерний для блока block2, и нет необходимости
сообщать ему об этом. Чтобы вставить данные в блок, достаточно
выполнить такой код столько раз, сколько нужно строк:
<?php
$tpl->setVariable(...);
$tpl->parseCurrentBlock();
?>
Чтобы внести контент в block1, нужно выполнить такое:
<?php
$tpl->setCurrentBlock("inner1");
$tpl->setVariable(...);
$tpl->parseCurrentBlock();
$tpl->setVariable(...);
$tpl->parseCurrentBlock();
$tpl->parse("block1");
?>
В итоге код скрипта выглядит так:
<?php
$tpl = new HTML_Template_IT( [string filerootdir] );
// загрузка шаблона или указание его через класс
$tpl->loadTemplatefile( string filename [, boolean removeUnknownVariables,
boolean removeEmptyBlocks] )
// установка переменных "global", т.е. переменных, не входящих в блок (дочерний блок)
$tpl->setVariable( string variablename, mixed value );
// ещё один способ указания переменных — через массив
$tpl->setVariable( array ( string varname => mixed value ) );
// Будем использовать какой-нибудь блок, пусть даже глубоко вложенный в другие
$tpl->setCurrentBlock( string blockname );
// Повторяем столько, сколько нужно
$tpl->setVariable( array ( string varname => mixed value ) );
$tpl->parseCurrentBlock();
// получаем результат или печатаем его вызывая $tpl->show()
$tpl->get();
?>
Код удобнее и понятнее, чем с FastTemplate.
Но многие программисты всё равно пишут свои собственные
классы шаблона. Более простые, но имеющие некоторые функции,
которых нет в общедоступных классах. Я писал собственный
класс, в котором сделал блоки, в которые автоматически
вставлялись результаты SQL-запросов, в добавок имелись шапка и
хвост блока (например, теги <table> и </table>),
которые появлялись в результате только если в SQL-запросе были
строки.
4.2 XML
В PHP3 появился модуль функций обработки XML. При помощи
функций этого модуля можно создавать собственных обработчики
XML-кода, но, однако, нельзя проверять правильность
XML-документа.
Небольшой экскурс в теорию о том, что такое XML и зачем
он нужен.
Приведу цитату из статьи "XML в 10
тезисах":
XML — это способ записи структурированных данных.
Под "структурированными данными" обычно подразумевают такие
вещи, как электронные таблицы, адресные книги,
конфигурационные параметры, финансовые транзакции, технические
чертежи и так далее. XML представляет собой набор правил (вы
можете также считать их инструкциями или соглашениями) для
разработки текстовых форматов, которые позволят вам
структурировать ваши данные.
Пояснение о том, что такое структура.
<eshop>
<!-- категории товаров -->
<category id="3">
<title>Мясные продукты</title>
<!-- Товары из данной категории -->
<commodity id="1">
<title>Рыба</title>
<measure-unit>килограмм</measure-unit>
<price>100</price>
</commodity>
<commodity id="3">
<title>Мясо</title>
<measure-unit>килограмм</measure-unit>
<price>200</price>
</commodity>
<!-- Подкатегория -->
<category id="15">
<title>Отходы производства</title>
<commodity id="2">
<title>Икра рыбья</title>
<measure-unit>килограмм</measure-unit>
<price>10</price>
</commodity>
</category>
</category>
<category id="10">
<title>Растительные продукты</title>
<commodity id="5">
<title>Подсолнух</title>
<measure-unit>штука</measure-unit>
<price>50</price>
</commodity>
</category>
</eshop>
Вот так в XML можно записать структурированные данные о
продовольственном магазине, в котором товары разделены на
категории, а категории могут быть подчинены друг другу.
Конечно, эти данные можно записывать по-другому, скажем, текст
с табуляторами в качестве разделителей и с указанием id
родительской категории (кстати, при записи данных в формате
XML, как видно выше, его указывать не нужно). XML — это
уже готовый формат для записи такой структуры, в рамках
которого вам остаётся лишь придумать названия узлов (тегов) и
правила, в которые должна укладываться структура (например,
что товар не может быть расположен вне категории или что
уровней категорий может быть не больше трёх). Далее:
XML — это не язык программирования, и вам не нужно
быть программистом, чтобы использовать или изучать его. XML
облегчает компьютеру задачу создания и чтения данных,
обеспечивая при этом однозначность их структуры. XML позволяет
избежать распространенных ошибок проектирования языков: он
расширяем, независим от платформы, включает поддержку
интернационализации и локализации. XML полностью совместим с Unicode.
(полный
текст статьи)
Разработчики php предлагают обрабатывать отдельные элементы
XML-документа функциями php. Пример из руководства по php:
<?php
$file = "data.xml";
// Массив обрабатываемых узлов
$map_array = array(
"BOLD" => "B",
"EMPHASIS" => "I",
"LITERAL" => "TT"
);
// Функция для начала тега (может выводить сложный текст, но в данном примере выдаёт
// просто соответствующий тег).
function startElement($parser, $name, $attrs) {
global $map_array;
if ($htmltag = $map_array[$name]) {
print "<$htmltag>";
}
}
// Функция для конца тега
function endElement($parser, $name) {
global $map_array;
if ($htmltag = $map_array[$name]) {
print "</$HTMLTAG>";
}
}
// Функция для текста (текстового узла)
function characterData($parser, $data) {
print $data;
}
$xml_parser = xml_parser_create();
// use case-folding so we are sure to find the tag in $map_array
xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, true);
xml_set_element_handler($xml_parser, "startElement", "endElement");
xml_set_character_data_handler($xml_parser, "characterData");
// Чтение XML-файла
if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}
while ($data = fread($fp, 4096)) {
if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
xml_parser_free($xml_parser);
?>
Данный пример можно расширить, добавив массив имён тегов,
которые будут обрабатываться иным образом, и соответствующие
условия в функции startElement и endElement.
Код выглядит просто ужасно. Для использования в
преобразовании XML в HTML-страницы он практически непригоден,
хотя кое-где применялся, например на сайте How IT works.
Конечно, можно писать собственные автоматизаторы, которые
читали бы конфигурационные файлы и создавали массивы, но по
суммарным трудозатратам выгоднее использовать мощные классы
шаблонов, такие как Smarty.
4.3 Smarty
Работа над этим проектом началась ещё в 1999 году, когда
группа разработчиков начала писать спецификацию движка
шаблонов. Определив, что он должен делать, разработчики
пытались написать модуль на C, но в конце концов решили, что
лучше сделать класс на php, доступный и понятный всем
разработчикам сайтов.
Сейчас Smarty — один из проектов PHP, его сайт
находится на сервере PHP по адресу smarty.php.net.
Формально Smarty — класс шаблона. На самом же деле,
его функциональность на порядок выше, чем у множества
*Template.
Во-первых, Smarty производит не только вставку переменных в
шаблон, но и выполняет php-код в самом шаблоне. Во-вторых,
шаблоны в Smarty преобразуются в php-скрипты, и всю грязную
работу по вставке переменных в текст и выполнению логических
конструкций отдаёт встроенному в php парсеру. Эти php-скрипты
при включённом кешировании сохраняются в файлы, которые
вызываются при следующих обращениях к шаблонам. Когда шаблоны
меняются, скрипты генерируются снова. Такое кеширование
существенно ускоряет работу скриптов.
Также Smarty умеет обрабатывать встроенные в шаблоны
логические конструкции if-else, преобразуя их в php-код.
Аналогично обрабатываются конструкции, названные variable
modifiers. Они позволяют убрать некоторые функции из основного
скрипта, перенеся их в шаблон и их кешируемые php-скрипты.
{* Написать заголовок заглавными буквами *}
<h2>{$title|upper},</h2>
{* Сократить топик до 40 символов, поставив ... в конце *}
Topic: {$topic|truncate:40:"..."}
Этот текст преобразуется в такой код:
<?php echo $this->_run_mod_handler('upper', true, $this->_tpl_vars['Name']); ?>
Topic: <?php echo $this->_run_mod_handler('truncate', true,
$this->_tpl_vars['Name'], 40, "..."); ?>
Доступен и набор встроенных переменных таких, как
$smarty.now (текущее время). Идилическую картину дополняет
вывод окна отладки, содержащего значения переменных, вызов
вложенных шаблонов, поддержка настраиваемых фильтров
ввода/вывода и плагинов.
Всё было бы прекрасно, будь Smarty меньше в размерах.
Сейчас же (версия 2.3.1) "весит" 144 килобайта и на AMD K6 266
MHz работает ощутимо медленно. Разработчики Smarty рекомендуют
использовать Zend
Accelerator или PHP Accelerator.
Автор благодарит Евгения
Степанищева и Антона Довгаля за
помощь и консультации при написании материала.
4.4 Торжество шаблонов:
php-templates
Движок шаблонов со средними возможностями - переменные и
блоки, но с самой большой скоростью работы, потому что сделан
как модуль для php. Соревноваться в скорости с ним не может ни
монстр Smarty, ни всякие классы *Template. Для установки
придётся перекомпилировать Apache на сервере или вписывать
модуль в php.ini под виндой.
Шаблон со списком товаров и ценами:
<html>
<head>
<title>Prices of ACME, Inc.</title>
</head>
<body>
<table border=1 cellspacing=0 cellpadding=2>
<tr>
<th>Product</th><th>Price</th>
</tr>
<tmpl:row>
<tr>
<td>{product}</td><td>{price}</td>
</tr>
</tmpl:row>
</table>
</body>
</html>
Код, достающий их из базы данных и вставляющий в
шаблон:
<?php
/* Код подключения к MySQL опущен */
$template = tmpl_open("prices.html");
$sql = "SELECT product, price FROM Products ORDER BY product";
$result = mysql_query($sql) or die("SQL error: ". mysql_error());
while($data = mysql_fetch_assoc($result)) {
tmpl_iterate($template, "row");
tmpl_set($template, "row", $data);
}
echo tmpl_parse($template);
?>
Создателям Smarty с их-то масштабом пора задуматься о
переводе своего класса в модуль.
В заключительной части: эра XML. XSL-трансформации на смену
шаблонам. SAX и DOM, Sablotron и libxml.
5. Sablotron, expat,
SAX-парсеры
В работе с XML-докуметами существует два подхода — SAX
(simple access to XML) и DOM (document object
model). Подход DOM — это работа с документом через
объектный программный интерфейс. SAX — это получение
данных при помощи парсера, обрабатывающего строку
XML-документа.
SAX-парсер можно написать самому, но делать это лучше
только в случает если задачка очень простая, либо если в
проекте XML не используется, а партнёры — вот
гады! — шлют RSS, NewsML и прочую разметку.
DOM-обработчик обычно не пишут, а используют готовый.
DOM — спецификация, описывающая, какие объекты должны
соответствовать каким узлам документа, какие методы и классы
должны содержать. Спецификация очень объёмная, поэтому одному
человеку её реализацию не написать. Для работы при помощи DOM
используются готовые библиотеки, самая известная из них —
libxml. В C/C++ эта библиотека подключается напрямую, в php
(написанном на C [исправлено. спасибо Profic]) есть
библиотека php_domxml, включающая в себя libxml и имеющая
надстройку для создания объектов DOM в среде php.
Итак, Sablotron и expat. Sablotron — это
XSLT-процессор, программа, выполняющая XSL-трансформации для
XML-документов. Sablotron использует expat — SAX-парсер
XML — для доступа к данным в документе.
Простые примеры использования XSLT можно встретить где
угодно. То, что находится уровнем выше и создаёт проблемы для
начинающих XSL-программистов, я описывал год назад в своём альтернативном
введении в XSLT и Sablotron.
Нет смысла их повторять, лучше посмотрим, что даёт XSLT в
плане организации шаблонов. В XSLT 1.0 есть мощный
инструмент — элемент xsl:import. Процессор трансформаций
открывает XSL-документ, указанный в элементе xsl:import, и
дополняет шаблонами из импортируемого документа основной
документ.
Приоритетом пользуются шаблоны в импортирующем документе.
То есть, если в обоих XSLT-файлах есть шаблоны с одинаковым
атрибутом select, в результирующий XSL-стиль берётся шаблон из
импортирующего документа.
При помощи такого импорта можно создавать локальные стили
для отдельных рубрик сайта. В локальном стиле описываются
шаблоны для тегов, которые есть в данной рубрике. Кроме того,
для отдельной рубрики можно переписать глобальный шаблон.
Очевидно так же, что имя импортируемого шаблона можно
менять через параметр.
Генерация XML-документов из текстовых строк — вот
первый шаг при переходе на систему XSLT-шаблонов.
Рекомендуется тем, кто не имеет опыта в DOM XML. Следующим
шагом будет замена тексто-ориентированной генерации документа
на объектно-ориентированную.
6. DOM XML
DOM — на данный момент последнее слово в шаблонах
документов в php. Я описывал модуль в статье «XML: спецификация и
функции DOM в PHP».
Несмотря на многословность и большой объём кода,
выполняющего достаточно простые операции, DOM XML имеет
большие перспективы.
Главный недостаток текстового подхода в редактировании
XML-документа (редактирования в скрипте, естественно) —
то, что нужно либо внимательно вчитываться в спецификицию XML,
либо не быть до конца быть уверенным в том, что же получилось
в итоге.
Например, вставить текст в узел — простая задача.
Однако в XML-документе служебные символы и символы, не
входящие в таблицу ISO, должны быть преобразованы в
XML-сущности (<) или в номера символов UTF-8
(&x0442;). В модуле DOM XML достаточно сконвертировать
текст в UTF-8 и вызвать метод create_text_node.
На моём сайте пока что работает старый движок, генерирующий
текстовую строку, и иногда он выкидывает интересные фокусы с
не-well-form-ными документами. Кроме того, объекты можно
передавать как параметр функции, а имя вызываемого метода
делать переменным.
Наконец, главное преимущество DOM XML — то, что
бинарный модуль для текстовой обработки документа в php
отсутствует. Это значит, что вам самим придётся писать парсер.
Что касается большого объёма кода, то это вполне
естественно. Ведь если вы хотите редактировать документ через
текст, то пишете регулярные выражения, используете набор
строковых функций. Этого кода нужно тоже немало, если
соблюдать условности XML.
Операции с документом через DOM нужно группировать в свои
собственные функции, то есть строить DOM-овый класс шаблона.
В отдельный шаблон можно вынести общие для сайта или его
разделов данные. Остальное — вставлять в документ
приёмом, который я описывал:
<?
$root1 = $dom1->document_element();
$child = $root1->child_nodes();
$root2 = $dom2->document_element();
for ($i = 0; $i < sizeof($child); $i++)
$root2->append_child($child[$i]->clone_node());
?>
Для сайта можно сделать простой скрипт, в который будут
перенаправляться запросы к документам. В .htaccess пишется
следующее:
Options FollowSymLinks
RewriteEngine On
# проверка наличия файла с тем же именем
# и расширением phpxml для корня раздела
RewriteCond %{DOCUMENT_ROOT}/$1/index.phpxml -f
# если такой файл есть, правило срабатывает
RewriteRule ^([a-z0-9_/-]+)/?$ /$1/index.php
# это правило сработает для адреса, переписанного
# по предыдущему правилу, и для всех остальных
# файлов, отправляя запрос в скрипт composer.php.
RewriteCond %{DOCUMENT_ROOT}/$1.phpxml -f
RewriteRule ^([a-z0-9_/-]+)\.php$ /composer.php [L]
В скрипте composer.php будет открываться файл с тем же
именем, что и запрашивался, но с расширением phpxml. Сервер
Apache при обработке правил уже проверил факт существования
этого файла.
Остаётся считать файл, вставить его содержимое в глобальный
шаблон и преобразовать через XSLT.
6.1 Валидация
документов
Это инструмент, который должен прийти на смену или
значительно потеснить самодельные средства проверки данных.
Сейчас стало модно отказываться от базы данных и хранить
данные в файлах.
С базой было просто: получаешь массив и делаешь из него
текстову строку (циклом или классом шаблона
наподобие php-templates), либо получить строку при помощи sql2xml дерево
объектов (или опять же строку). С файлом работать сложнее,
потому что на всякий случай желательно проверять целостность
данных.
Есть два подхода в создании разметки. Первый —
разметка, ориентированная на данные (data-centric markup),
второй — разметка, ориентированная на документ
(document-centric markup).
Пример разметки ориентированной на данные:
<?xml version="1.0"?>
<championship-list>
<championship>
<acro>ETCC</acro>
<title>European Touring Car Championship</title>
<description>FIA-organized racing series. Uses racing cars.</description>
<site></site>
</championship>
<championship>
<acro>BTCC</acro>
<title>British Touring Car Championship</title>
<description>Analogue to ETCC, except that races take.</description>
<site>http://btcc.co.uk</site>
</championship>
<championship>
<acro>DTM</acro>
<title>Deuche Tourenwagen Masters</title>
<description>Most famous German Touring racing series. </description>
</championship>
</championship-list></no-escape>
Два уровня иерархии — строка + поле (естественно, если
их станет 3 или 4, качественно ничего не изменится), в общем,
то же самое, что и запрос из базы данных, отформатированный
при помощи sql2xml. Пример документо-ориентированной
разметки:
<?xml version="1.0"?>
<championship-list>
FIA organized about 20 racing servies, including 2 touring cars championships.
<championship><title>European Touring Car Championship</title>
(<acro>ETCC</acro>) uses significantly tuned road cars, mostly BMW.</championship>
<championship>Another FIA series is <title>British Touring Car</title>
(<acro>BTCC</acro>) is analogue to ETCC, except that races take.</championship>
Allthough, these are not the world's most famous championships.
<championship><acro>DTM</acro> (<title>Deuche Tourenwagen Masters</title>),
the most famous Touring racing series not only in Germany.</championship>
</championship-list>
Этот вариант написан свободным человеческим языком, но
данные в элементах acro и title остались те же, их можно
получить из документа теми же запросами XPath или XQuery: /championships/championship[acro='DTM']/title Первый
вариант разметки можно представить в виде таблицы базы данных.
Можно усложнить его, для примера — фрагмент
документа:
<championship>
<acro>DTM</acro>
<title>Deuche Tourenwagen Masters</title>
<description>Most famous German Touring racing series.</description>
<drivers>
<driver>Laurent Aiello</driver>
<driver>Bernd Schneider</driver>
<driver>Marcel Fassler</driver>
<driver>Jean Alesi</driver>
<driver>Cristian Albers</driver>
</drivers>
</championship>
От этого документ не перестанет быть data-centric. Новый
документ можно представить как 2 таблицы, соединяемые при
запросе оператором LEFT JOIN.
Второй документ имеет более сложную структуру, и в общем
случае его не получится запихать в таблицу.
Кстати, в этом заключается основное отличие XML-баз данных
от не-XML. XML-database работает и с разметкой,
ориентированной на документ (а не только в том, что результаты
выдаются в XML). Разметку же типа data-centric вполне можно
хранить в реляционной БД, а на выходе форматировать утилитой
вроде sql2xml.
Так вот, возвращаясь к валидации документов, нужно
заметить, что документо-ориентированную разметку очень сложно
проверить на соответсвтие DTD или XML-схеме простым строковым
парсером.
Ещё пример — разметка формы в моём классе TXF:
<?xml version="1.0" encoding="windows-1251"?>
<txf:form xmlns:txf="http://txf.sourceforge.net/" name="item"
action="category.php" receive-method="ANY" suggest-method="POST">
<txf:rule>
<txf:revswitch true="0">
<txf:logic type="and">
<txf:logic type="or">
<txf:func name="my_email_check">
<arg select="//txf:input[@name = 'email']/value"
setInvalid="//txf:func[@name = 'email']/value"/>
</txf:func>
<txf:trigger test="not(//txf:input[@name = 'send_email']/value)"/>
</txf:logic>
<txf:trigger test="string-length(//txf:input[@name = 'login']/value) > 0"/>
</txf:logic>
</txf:revswitch>
<txf:revswitch true="1">
<txf:trigger test="string-length(//txf:input[@name = 'login']/value) = 0 and
string-length(//txf:input[@name = 'email']/value) = 0
</txf:revswitch>
</txf:rule>
</txf:form>
Я проверяю это через DTD-схему. Проверка соответствия схеме
документа — стандартная функция библиотеки DOM XML.
Для общеиспользуемых форматов обмена данными, например,
RSS, есть спецификации и DTD-схемы (XML-схемы). Чтобы не
забивать голову написанием собственного RSS-парсера, можно
просто добавить в документ схему и проверить на допустимость.
Затем доставать из документа нужные узлы через get_content или
выражения XPath.
6.2 Лирическое
отступление
Срочно завершать написание этой части серии меня заставила
последняя заметка Spectator-a под названием «Шаблоны
в PHP для чайников».
Автор, Дмитрий Смирнов, непринуждённо, с экслеровской
простотой доказывает, чем хороши шаблоны, сделанные при помощи
кставок php-кода такого вида:
Призывает забыть слова типа XML, XHTML «и прочий X...»,
попутно даёт заслуженного пинка Smarty, и, завершая свой
ЭКСпромт, призывает умников бриться бритвой Оккама.
Бедная бритва! Подняли на знамёна её, машут ей везде, где
можно, тыкают и пытаются нанести ею увечья оппонентам.
К чёрту бритву! К чёрту это дурацкое правило "не плодить
сущности сверх необходимого". Это слишком избитая истина,
чтобы её напоминать людям, а для того, чтобы оценивать других
она вообще не годится. Количество "сверх необходимого" для
каждого человека разное. Заказчик сайта может сказать: "А
зачем мне ваши скрипты, сделайте в простом HTML, чтобы мы
потом FrontPage-ом могли редактировать! Читали про бритву
Оккама?"
Я долгое время считал, что основная причина, почему стоит
использовать новые технологии в программировании — это
эффект масштаба. Как мне написали в комментариях к старой
статье, "с ростом объёмов сайта ты утонешь в своих шаблонах".
И в своих статьях я упирал именно на это — мол,
пожалуйста, балуйтесь со своим хитрым include и кодом,
смешанным с HTML, оно поперёк горла встанет, когда надо будет
сделать много программного кода.
На самом деле, есть ещё одна причина. Это навыки каждого
конкретного человека. Кто хорошо знает XML, XSLT и XPath, либо
умеет быстро находить решения задач в этой среде, тот в
большем количестве случаев выполнит проект именно на
XML-технологиях. Ему это сделать будет просто и легко, потому
что он это хорошо умеет. Кто не знает или знает плохо —
будет делать "простонародными" способами.
Остаётся лишь вопрос, будут ли его решения на
XML-технологиях эффективнее, чем если бы он делал на классах
шаблона или смешанном PHP&HTML? Да, будут. Приведу
аллегорическое сравнение.
Вы видели, как играют в волейбол опытные игроки и "ламеры"?
Команды "кульков" правдами и неправдами перекидывают мяч на
другую сторону, чтобы соперник уронил мяч у себя. Нападающий
удар они делать не умеют, и, руководствуясь пресловутой
бритвой, играют просто. Опытный игрок намного лучше кулька
умеет перекидывать мяч. Однако большего результата он
добьётся, если выполнит хороший нападающий
удар.
