Зато одноразовый, так как XSLT - стандарт, и рано или поздно можно будет найти верстальщика, знающего XSLT. Попробуйте нати верстальщика под MACRO.
Пример был приведен как приблизительная аналогия коду:
<xsl:template match="chapter">
<fo:block>
<xsl:apply-templates/>
</fo:block>
</xsl:template>Являются, но не теми, которые необходимы шаблонизатору.
Ну ты же понимаешь что плохая реализация не является критерием оценки самого подхода...
Я давно пользуюсь. А до того как начал пользоваться тоже писал шаблонизатор, который можно увидеть в PHP_Application. Шаблонизатор очень простенький и поместился всего в одном файле, но тем неменее в нём заложены большие возможности, делающие его достаточно гибким. Однако после некоторого времени разработки понял, что иду по пройденному пути XSLT, после чего окончательно перешёл на него, хотя и его возможностей уже не хватает.
Интересно. А каких именно возможностей не хватает?
Ну ни фига себе у Вас требования к шаблонизаторуАвтор оригинала: atv
Наследования и полиморфизма. То что делает ООП таким гибким и реюзабельным.
<xsl:variable name="tmpl" select="..."/>
<xsl:import href="$tmpl"/>
Его можно обучить, гораздо быстрее, чем дождаться верстальщика XSLT, и обходится он дешевле
Вы про наследование и полиморфизм? Может на примере? Использование одной функции в другой это не частный случай наследования, т.е. добавления функциональности к уже существующей (по большому счету)?
Пожалуйста покажите мне хорошую, я два года ее ищу.
Тем более зачем себя ограничивать каким-то стандартом, если вы из него выросли? Используйте РНР!
Ты мне прямо-таки открыл глаза. Давай так, я тебе покажу конкретный пример с MACRO, а ты поделишься примером, как для этого случая отработают твои контроллеры?
<?php $news = News :: findLatest(); ?>
{{list using="$news" as="$item"}}
<div id='news'>
{{list:item}}{$item.title}...{{/list:item}}
{{list:glue}}<hr/>{{/list:glue}}
</div>
{{/list}}...
<!-- где-то по центру-->
{{include file="include/news.phtml"}}
......
<!-- где-то в левой колонке -->
{{include file="include/news.phtml"}}
...<data>
<news>
<item>blah-blah-blah</item>
<item>blah-blah-blah</item>
<item>blah-blah-blah</item>
</news>
<menu>
<item>blah-blah-blah</item>
<item>blah-blah-blah</item>
<item>blah-blah-blah</item>
</menu>
<submenu>
<item>blah-blah-blah</item>
<item>blah-blah-blah</item>
<item>blah-blah-blah</item>
</submenu>
<user>
<name>foo</name>
<id>1024</id>
<age>128</age>
</user>
<content>
blah-blah-blah
</content>
</data>Где я сказал, что это плохо? MACRO это тоже поддерживает.
Причем здесь контроллер? Я показал пример, как MACRO работает _напрямую_ с моделью без ненужной в данном случае прослойки из контроллера. XSLT это умеет?
Вот серьезно, ты где в реальном проекте это использовал? Ну да, давайте мне еще про абстрактную возможность генерации pdf расскажите при помощи XSLT. Если уж меня столь сильно припечет, я с помощью MACRO нагенерю и XML и XSLT преобразование, которое передам на клиента.
Я хотел сказать, что плохого в том, что XSLT поддерживает только PushView?
Нет. Эту возможность имеет смысл рассматривать, для снижения нагрузки на сервер. Я с такого рода оптимизацией ещё не сталкивался. Но лично проверял, что это работает. И лиса, и эксплорер без проблем справляются с xslt преобразованием шаблонов типичного сайта.
MACRO в этом случае будет лишней прослойкой. Хотя это лишний раз доказывает, что MACRO можно использовать для любых задач.
Было-бы интересно посмотреть на реализацию XPath на php.
А что в этом хорошего? На лицо явное ограничение, которое значительно усложняет жизнь разработчика.
Стандартный для кого? Для руководителей, которые живут в иллюзорном мире различных парадигм и "грамотном разделении приложения на слои"? Которые заставляют верстальщика мучиться с XSLT красотами вместо того, чтобы быстро, и самое главное, понятно решать задачу?
А никто с этим и не спорит. Узкоспециализированный инструмент всегда эффективнее абстрактного и неуклюжего монстра.
А я не понимаю, за что его любить-то? Эра повальной XML-мании и hype'а на эту тему успешно закончилась, аминь! Да, XML хорош в некоторых частных случаях(например, передача данных, хотя опять же это спорное утверждение), но зачем же его стараться пихать везде? Наверное, не спроста разработчики меняют неуклюжие XML конфиги на YAML, или используют rake вместо Ant?Я не понимаю, почему такое странная неприязнь к xml и xslt в частности...
Давай еще вспомним про XForms и другие греющие душу призрачные клиентские технологии.
Нет, я всего лишь имел в виду возможность генерации XSLT при помощи шаблона MACRO.А на счет XSLT-преобразования не понял. Ты это серьёзно?
Сомнительно, что получится так просто избавиться от последствий XML-мании. Слишком много завязано на нем. Это и HTML и DOM, благодаря которому появились такие замечательные вещи как jQuery и различные wisiwyg-редакторы.
Эм... Если это на счет xslt. То, наверное, должен быть какой-то намек на DOMDocument, XSLTProcessor...Автор оригинала: dark-demon
ну вот простейший контроллер:
...
или опять не то?