-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Идеальный шаблонизатор
- Автор темы С.
- Дата начала
- Статус
С.
Продвинутый новичок
Идеальный шаблонизатор, рассматриваемый в данной теме, привязан. Иначе мы имеем опасность не получить конкретной реализации или получить такую сугубо абстратктную реализацию, которой будут пугать детей. XSLT уже номинант в этой категории.
Кто сказал, что наш идеальный шаблон должен быть похожим на XSLT'шный? В данном конкретном случае, когда блок <LI> вынесен за пределы <UL>, это добавяет лишнюю абстракцию или условность, совершенно ненужную для нашего идеального шаблона. В данном случае нахождение <LI> между <UL> (где ему и положено по логике) -- обязательное условие контрольной задачи.
К этому списку мы как раз должны подойти. Это и будет шаблонизатор с расширенной функциональностью, который мы ищем или создаем. Единственный имеюшийся на данный момент как-то соответствующий ему - XSLT. Но для того и даны были две контрольных задачи, чтобы не уплывать в облака. Соответствовать-то идее он соответствует, но как решает конкретные задачи?
-~{}~ 15.10.07 15:35:
Даю установку: в этой теме забыли про скорости!
-~{}~ 15.10.07 15:40:
Не надо хвастаться, чей шаблон короче и чьи новости новее. Давайте примеры реализации построения дерева и форм.
atv
Новичок
Ты вед не пользовался XSLT ;-)
table/row/cell - это данные во входном XML документе. Фактически table/row/cell можно заменить на что угодно, хоть на plain text.
Отображение будет происходить как раз по тем самым правилам
А входными данными является XML документ. который передаётся шаблонизатору.
Ещё раз повторю, не нужно никаких циклов для отображения XML данных, это ограничивает повторное использование шаблонов.
Ага, а как же повторное использование кода?
"Покупатели имеют возможность купить автомобиль любого цвета, при условии что этот цвет чёрный" (с) Генри Форд.
CatManZero
Новичок
Пожалуйста. Шаблон дерева. ul и li в одном флаконе:
PHP:
<xsl:template name="tree">
<xsl: param name="nodes"/>
<xsl:if test="$nodes">
<ul>
<xsl:for-each select="$nodes">
<!-- содержание узла -->
<li><xsl:value-of select="."/>
<!-- рекурсивный вызов -->
<xsl:call-template name="tree">
<xsl:with-param name="nodes" select="node"/>
</xsl:call-template>
</li>
</xsl:for-each>
</ul>
</xsl:if>
</xsl:template>
PHP:
<xsl:call-template name="tree">
<xsl:with-param name="nodes" select="/site/tree/node"/>
</xsl:call-template>CatManZero
Новичок
Это почему же не надо? И чем это они ограничивают повторное использование?
atv
Новичок
У очевидности бывают разные границы. Самым очевидным будет PHP код в перемешку с HTML в пределах 100 строчек. Больше этого количества очевидность уже теряется. Приходиться как-то структурировать код, а очевидность уже будет опираться не только на видимое представление, но и на правила структурирования, которые необходимо в этом случае знать.
Для меня приведенный пример на XSLT вполне очевиден, так как я знаю правила, по которым он будет обрабатываться. Точно так же PHP код может быть очевидным или не очевидным, в зависимости от правил по которым он структурируется. Если человек знаком только с функциями и не знаком с классами, то ООП код будет для него неочевидным.
XSLT обработку легко представить на PHP.
Представьте себе класс XSLTProcessor у которого есть управляющие инструкции (методы) apply-templates, value-of, for-each и т.д.
Код:
class XSLTProcessor
{
function applyTemplates($select) {...}
function valueOf($select) {...}
function forEach($select) {...}
function transform($inputData, $template) {...}
}В структкре данных используются не просто названия переменных а ещё и типы переменных.
Логика преобразования остаётся неизменной. Алгоритм работы метода transform - это и есть:
Правила эти очень простые: взять корневой элемент входных данных и найти для него шаблон преобразования, поиск производиться по типу элемента. Если шаблон не найден, то всё, преобразование закончено. Если найден обрабатывается шаблон.
Код:
class XSLTProcessor
{
function transform($inputData, $template)
{
if ($this->isTemplateExists($inputData->getRoot())) {
$this->applayTemplates($inputData->getRoot());
}
}
}Далее, если в шаблоне не встречается инструкция apply-templates, то преобразование заканчивается, если инструкция присутствует, то выбирается следующий элемент входных данных в зависимости от параметра select инструкции apply-templates. По умолчанию, параметр select указывает на дочерние элементы текущего обрабатываемого элемента.
Таким образом рекурсивно происходит обработка всех входных данных.
А шаблон в нашей аналогии будет представлять собой класс XSLTTemplate у которого определены методы (шаблоны) для каждого типа входных данных.
Код:
class XSLTTemplate
{
function rootTemplate($inputData)
{
print '<html>';
$this->xslt->applyTemplates($inputData->getChildrens());
print '</html>';
}
function selectTemplate($inputData) {...}
function inputTemplate($inputData) {...}
// и т.д.
}Как видите, ничего сложного в XSLT нет. Для PHP программиста такая аналогия должна быть понятной. И должно быть понятно, почему лучше не использовать циклы, а написать несколько небольших шаблонов.
Использование XML для написания шаблонов плохо только тем, что нет доступной IDE которая имела бы возможность подстановки xslt инструкций, а так, ни чем не страшнее ООП
Dagdamor
Новичок
atv
Напиши полный пример, не вырезку из XSLT-шаблона, которая должна поразить мое воображение, а работающий пример. Все это выглядит очень подозрительно, я не понимаю, как можно собрать таблицу с данными, не используя итератор.
Напиши полный пример, не вырезку из XSLT-шаблона, которая должна поразить мое воображение, а работающий пример. Все это выглядит очень подозрительно, я не понимаю, как можно собрать таблицу с данными, не используя итератор.
Это не так. Шаблоны на Смарти, даже достаточно сложные, вполне понятны новичку. Я в свое время разбирался со Смарти по примерам, без какой-либо документации. В случае XSLT такой номер не пройдет.
CatManZero
Новичок
Ага. А затем это нужно объяснить верстальщику, который в лучшем случае знаком с основами php...
Dagdamor
Новичок
atv
Рекурсию?? Это было неожиданно
А как же ограничение PHP на максимальный уровень рекурсии (100 вызовов, кажется)? Что, если на странице отображается более 100 записей?
С.
Имхо, это порочный подход. Шаблонизатор должен быть устроен так, чтобы диктовать правила отображения данных, а не зависеть от их структуры. Другими словами, должна быть система "шаг влево, шаг вправо - стреляю". В противном случае любые ошибки в структуре исходных данных будут приводить к непредсказуемому отображению их в шаблоне, это будет очень сложно отследить и отладить.
Гипотетический пример: выводим таблицу, для каждой строки выводится набор дополнительных полей, которые вычисляются предварительно. Допустим, для одной строки одно из полей вычислено не было, отсутствует. В нормальном шаблонизаторе будет выведена пустая ячейка таблицы + notice о не найденном индексе массива. В XSLT, похоже, ячейка будет попросту пропущена, и таблица разъедется без каких-либо сообщений об ошибках.
Рекурсию?? Это было неожиданно
А как же ограничение PHP на максимальный уровень рекурсии (100 вызовов, кажется)? Что, если на странице отображается более 100 записей?
С.
Имхо, это порочный подход. Шаблонизатор должен быть устроен так, чтобы диктовать правила отображения данных, а не зависеть от их структуры. Другими словами, должна быть система "шаг влево, шаг вправо - стреляю". В противном случае любые ошибки в структуре исходных данных будут приводить к непредсказуемому отображению их в шаблоне, это будет очень сложно отследить и отладить.
Гипотетический пример: выводим таблицу, для каждой строки выводится набор дополнительных полей, которые вычисляются предварительно. Допустим, для одной строки одно из полей вычислено не было, отсутствует. В нормальном шаблонизаторе будет выведена пустая ячейка таблицы + notice о не найденном индексе массива. В XSLT, похоже, ячейка будет попросту пропущена, и таблица разъедется без каких-либо сообщений об ошибках.
atv
Новичок
В вызове "$this->xslt->applyTemplates($inputData->getChildrens());" присутствует и рекурсия и итерация. Просто вложенной итерации нет, она заменена рекурсией.
Проверки можно разместить на многих уровнях приложения, не только в шаблонизаторе. Вопрос в том, какая проверка на каком уровне уместна. Контроль входных данных, по моему, не совсем уместная задача для шаблонизатора.
С.
Продвинутый новичок
Подвожу промежуточные итоги.
1). Идеальный шаблонизатор в качестве "расширения" базовой функциональности должен обладать возможностью задавать шаблонные правила.
Единственным кандидатом пока выступил XSLT. Но рассмотрев XSLT выяснилось, что его концепция несколько иная, чем нам требуется. "Королем" в технологии XSLT явлется программист, предоставляющий входящий XML поток, а дизайнер с XSL его обслуживает. В определении XSLT is used to transform an XML document into another XML document, or another type of document that is recognized by a browser, like HTML and XHTML даже сам шаблон не упоминается, как просто "рабочий" момент.
Мы же рассматриваем вариант, когда программист предоставляет данные, чтобы обслужить дизайнера. Дизайнер - король и его шаблон - отправная точка. Таким образом:
2). Идеальный шаблонизатор предназначен для трансформирования HTML документа в HTML документ.
То есть в "сыром" не трансформированом виде шаблон уже должен являться практически корректным HTML документом. Никаких таких "этот блок должен быть внутри, но мы его помещаем снаружи потому, что мне (программисту) так удобнее".
1). Идеальный шаблонизатор в качестве "расширения" базовой функциональности должен обладать возможностью задавать шаблонные правила.
Единственным кандидатом пока выступил XSLT. Но рассмотрев XSLT выяснилось, что его концепция несколько иная, чем нам требуется. "Королем" в технологии XSLT явлется программист, предоставляющий входящий XML поток, а дизайнер с XSL его обслуживает. В определении XSLT is used to transform an XML document into another XML document, or another type of document that is recognized by a browser, like HTML and XHTML даже сам шаблон не упоминается, как просто "рабочий" момент.
Мы же рассматриваем вариант, когда программист предоставляет данные, чтобы обслужить дизайнера. Дизайнер - король и его шаблон - отправная точка. Таким образом:
2). Идеальный шаблонизатор предназначен для трансформирования HTML документа в HTML документ.
То есть в "сыром" не трансформированом виде шаблон уже должен являться практически корректным HTML документом. Никаких таких "этот блок должен быть внутри, но мы его помещаем снаружи потому, что мне (программисту) так удобнее".
CatManZero
Новичок
А как верстальщику это объяснить? Вот подготовил верстальщик верстку. Программист превратил их в шаблоны. Завтра говорят верстальщику. Вот мы добавили новую фишку на сайт. Оформи ее. Он открывает шаблон и вместо своей верстки видит мешанину ввиде <apply-templates> и <templates>. Как ему объяснить как они взаимодействуют?
Кстати, именно по этой причине я когда-то отказался от этих apply-templates. Когда шаблоны становятся сложнее, чем "меню справа-по середине текст", apply-templates начинают конфликтовать друг с другом самым наглым образом. А @mode вносят в эту мешанину ещё больше хаоса. И ни как не способствуют "повторному использованию шаблонов".
Дело в том, что у нас в компании такое разделение труда:
1) дизайнер готовит макет
2) верстальщик используя photoshop и html-редактор превращает макет в верстку. Делает так, что б она отображалась правильно во всех популярных броузерах. Соответственно знать php ему не обязательно и обходится такой верстальщик дешевле.
3) программист "натягивает" верстку на движок. Превращает их в шаблоны.
4) затем верстальщик может привлекаться для окончательной доводки сайта до кондиции. А также при добавлении новой функциональности, когда ее нужно оформить.
- Статус