“Долбанный будильник!” – выругнулся в подушку Хэкер и, не поднимая головы, потянулся рукой к находившемуся рядом столу. Стоявшие на нем пустые пивные бутылки с грохотом покатились на пол, пока рука Хэкера щупала пространство на столе, пытаясь достать этот ужасный девайс, но тщетно.
Поднявшись и расправившись с будильником, сидя на краю кровати, Хэкер посмотрел в зеркало, висевшее напротив. ”Паршиво выглядишь”, – подумал он.
Сегодня он должен высказать свои соображения по шаблонизатору перед Высшим Хэкерским Советом, однако, этих соображений — ровно, как и желания присутствовать на совете — не было.
Хэкер поднялся с кровати. Умывшись холодной водой и походив взад-вперед по комнате, он задумчиво посмотрел в окно. В доме, что напротив, рабочие под присмотром дамочки с собачкой меняли окна фасада.
“Окна, окна… – думал Хэкер. – Окна – это Windows; Windows, Windows....Windows – это тормоза, тормоза — это черепаха; черепаха, черепаха… черепаха — это Subversion клиент...Subversion??? “
“Эврика! ” – воскликнул Хэкер. Решение пришло само собой. Теперь он знал, что он будет предлагать на совете.
Итак, речь пойдет об очередном велосипеде под названием шаблонизатор. Основой нашего шаблонизатора станет система контроля версий Subversion и ее замечательный механизм хуков. В данном случае нам будет нужен post-commit хук, выполняющийся после того как транзакция (внесение изменений в репозиторий) была завершена.
Попробуем разобраться, зачем нам нужен еще один велосипед.
Во-первых, мы хотим максимально автоматизировать все рабочие процессы. Во-вторых, мы хотим максимально облегчить жизнь верстальщика и программиста, непосредственно участвующих в рабочем процессе. В-третьих, мы хотим создать более мощное и простое решение их тех, что существуют сейчас.
Каждый верстальщик желает видеть как можно меньше “non-HTML” разметки. Человек, незнакомый с таким широко известным шаблонизатором как Smarty (а таких немало), не сразу воспримет такую разметку: www.smarty.net/manual/en/language.basic.syntax.php
Дадим верстальщику такую возможность и будем использовать в шаблонах конструкции, отвечающие HTML синтаксису. Первое преимущество, вытекающее из этого: верстальщик может использовать для работы статические страницы.
Попробуйте посмотреть, как отображает браузер пример, данный по ссылке выше, и следующий:
Неизвестные теги if, for, include браузеры будут игнорировать, а результирующий вывод будет полностью соответствовать тому, что будет после обработки документа шаблонизатором (не считая тех частей, которые не будут включены в вывод).
Помимо этого у нас появляется мощный инструмент для синтаксического разбора шаблонов: DOM-парсер. Так как все конструкции шаблонов у нас соответствуют HTML синтаксису, все теги вроде <if cond=”$a > $b”></if> очень легко превращаются в соответствующий PHP-код.
Рассмотрим файловую структуру шаблонизатора, на примере данном выше, и что происходит, когда верстальщик работает с HTML документом in vivo:
Страницы index.html содержит несколько шаблонов: header, footer, lsb и blockA. После того как верстальщик вносит изменения в документ (изменяет один из шаблонов, либо добавляет новый) он заносит изменения в репозиторий (svn ci –m “index.html update”). Сразу поле этого отрабатывает post-commit хук, который выполняет следующее:
Каждому шаблону соответствует PHP класс, наследуемый от базового класса Template. Класс автоматически подгружает нужный ему шаблон (разметка + PHP код после обработки шаблонизатором), принимает необходимые данные и возвращает на основании их тело шаблона (архитектура MVC). Шаблоны так же могут быть вложенными.
Таким образом, используя нехитрую технику, мы получаем решение, которое намного гибче любых других (по крайне мере из тех, что известны автору).
Все это на уровни идеи, но если кто-либо пожелает реализовать и использовать данную технику, то автор с удовольствием окажет посильную помощь.
Поднявшись и расправившись с будильником, сидя на краю кровати, Хэкер посмотрел в зеркало, висевшее напротив. ”Паршиво выглядишь”, – подумал он.
Сегодня он должен высказать свои соображения по шаблонизатору перед Высшим Хэкерским Советом, однако, этих соображений — ровно, как и желания присутствовать на совете — не было.
Хэкер поднялся с кровати. Умывшись холодной водой и походив взад-вперед по комнате, он задумчиво посмотрел в окно. В доме, что напротив, рабочие под присмотром дамочки с собачкой меняли окна фасада.
“Окна, окна… – думал Хэкер. – Окна – это Windows; Windows, Windows....Windows – это тормоза, тормоза — это черепаха; черепаха, черепаха… черепаха — это Subversion клиент...Subversion??? “
“Эврика! ” – воскликнул Хэкер. Решение пришло само собой. Теперь он знал, что он будет предлагать на совете.
Итак, речь пойдет об очередном велосипеде под названием шаблонизатор. Основой нашего шаблонизатора станет система контроля версий Subversion и ее замечательный механизм хуков. В данном случае нам будет нужен post-commit хук, выполняющийся после того как транзакция (внесение изменений в репозиторий) была завершена.
Попробуем разобраться, зачем нам нужен еще один велосипед.
Во-первых, мы хотим максимально автоматизировать все рабочие процессы. Во-вторых, мы хотим максимально облегчить жизнь верстальщика и программиста, непосредственно участвующих в рабочем процессе. В-третьих, мы хотим создать более мощное и простое решение их тех, что существуют сейчас.
Каждый верстальщик желает видеть как можно меньше “non-HTML” разметки. Человек, незнакомый с таким широко известным шаблонизатором как Smarty (а таких немало), не сразу воспримет такую разметку: www.smarty.net/manual/en/language.basic.syntax.php
Дадим верстальщику такую возможность и будем использовать в шаблонах конструкции, отвечающие HTML синтаксису. Первое преимущество, вытекающее из этого: верстальщик может использовать для работы статические страницы.
Попробуйте посмотреть, как отображает браузер пример, данный по ссылке выше, и следующий:
<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title>iSvnTemplate example</title>
<style type="text/css">
#header, #footer, #lsb { font-size:24px; color: white; }
#header, #footer {
width:100%;
height:50px;
background-color:#303030;
text-align:center;
line-height:50px;
}
#footer {
clear:both;
}
#lsb {
border:1px solid green;
margin:2px;
min-height:200px;
width:90px;
float:left;
}
</style>
</head>
<body>
<!-- Template container. -->
<cont name="header">
<div id="header">
Header
</div>
</cont>
<cont name="lsb">
<div id="lsb">
Lsb
</div>
</cont>
<cont name="blockA">
<div id="blockA">
<!-- Support of conditional expressions. -->
<if cond="$a > $b">
<h2>A is greater than B</h2>
</if>
<else>
<h2>B is greater than A</h2>
</else>
<!-- Support of loops. -->
<for cond="$i = 0; $i < 8; $i++">
<!-- Including another template. -->
<include file=""/>
</for>
<php>
print "<b>Hello, World!</b>"
</php>
</div>
</cont>
<cont name="footer">
<div id="footer">
Footer
</div>
</cont>
</body>
</html>
* This source code was highlighted with Source Code Highlighter.Неизвестные теги if, for, include браузеры будут игнорировать, а результирующий вывод будет полностью соответствовать тому, что будет после обработки документа шаблонизатором (не считая тех частей, которые не будут включены в вывод).
Помимо этого у нас появляется мощный инструмент для синтаксического разбора шаблонов: DOM-парсер. Так как все конструкции шаблонов у нас соответствуют HTML синтаксису, все теги вроде <if cond=”$a > $b”></if> очень легко превращаются в соответствующий PHP-код.
Рассмотрим файловую структуру шаблонизатора, на примере данном выше, и что происходит, когда верстальщик работает с HTML документом in vivo:
/view
/static
index.html
/template
header.tpl
lsb.tpl
footer.tpl
blockA.tpl
/logic
header.tpl.php
lsb.tpl.php
footer.tpl.php
blockA.tpl.php
Страницы index.html содержит несколько шаблонов: header, footer, lsb и blockA. После того как верстальщик вносит изменения в документ (изменяет один из шаблонов, либо добавляет новый) он заносит изменения в репозиторий (svn ci –m “index.html update”). Сразу поле этого отрабатывает post-commit хук, который выполняет следующее:
- Считывает все содержимое директории /view/static
- Осуществляет парсинг документов, найденных на этапе 1.
- Извлекает все шаблоны и обновляет содержимое директории /view/template
- Добавляет (либо удаляет) каркасы классов в директорию /view/logic в случае, если был обнаружен новый шаблон
Каждому шаблону соответствует PHP класс, наследуемый от базового класса Template. Класс автоматически подгружает нужный ему шаблон (разметка + PHP код после обработки шаблонизатором), принимает необходимые данные и возвращает на основании их тело шаблона (архитектура MVC). Шаблоны так же могут быть вложенными.
Таким образом, используя нехитрую технику, мы получаем решение, которое намного гибче любых других (по крайне мере из тех, что известны автору).
Все это на уровни идеи, но если кто-либо пожелает реализовать и использовать данную технику, то автор с удовольствием окажет посильную помощь.
