всем хорош xslt да только многословен он уж слишком. xstyle использует processing instruction чтобы ввести набор макросов для различных конструкций xslt. например, когда вам нужно вывести значение переменной, в xslt приходится писать так: <xsl:value-of select=" $var " /> в xstyle для этого достаточно написать <?val $var ?> (есть вариант с <?: $var ?>, но на него варнинги сыпятся ._.) бывает нужно просто вставить пробел в вывод и тогда приходилось писать: <xsl:text> </xsl:text> теперь же для этого есть короткая запись: <?space?> можно делать инклуды <?include included-file.xs ?> причём все подключаемые таким образом файлы будут вкомпилированны в текущий. подключать можно не только xs, но и xsl файлы, ведь xstyle - это обратно совместимое расширение xslt, то есть внутри xs-файлов можно использовать как xstyle, так и xslt конструкции. это были простые тэги, но есть и составные: открывающие заканчиваются минусом, а закрывающие точкой. например, аналогом такой конструкции: <xsl:if test=" @count > 5 "> ого, сколько! </xsl:if> будет такая: <?if- @count > 5 ?> ого, сколько! <?if.?> или даже такая: <?if @count > 5 \ 'ого, сколько!' ?> во многих конструкциях бэкслэш используется в качестве разделителя параметров, поэтому в внутри значений он быть не может. кстати. обратите внимание, что спецсимволы xml не надо экранировать, так что условия со сравнениями выглядят гораздо читабельнее ;-) <xsl:template match="p"> записывается как <?match- p ?> <xsl:template match="p" mode="copy"> как <?match- p \ copy ?> <xsl:template mode="copy"> как <?match- \ copy ?> <xsl:template> как <?match- ?> полный набор синтаксиса можно найти в тестах (как видно не всё ещё реализовано, но это мелочи ;-)). сам компилятор написан на xslt, так что проблем с переносом его на другие платформы быть не должно. для php написан класс XStyle, который автоматически при необходимости перекомпилирует .xs файлы в .xsl и кладёт их рядом с ними. использовать её просто: $xstyle= new XStyle( 'templates/thing.xs' ); $res= $xstyle->process( $doc ); echo $res->saveHTML(); $doc и $res - экземпляры DOMDocument скачать, поиграться и сравнить производительность с другими популярными шаблонизаторами можно тут (php,smarty): http://mojura.110mb.com/test/xslt-vs-sm ... smarty.zip
сколько спеси у тебя за последнюю пару лет появилось.. наверно измуряющая работа над очень нагруженными проектами даёт о себе знать? %-)
Тигра ты чтоли это? врятли. Два человека говорят что в общем случае это маразм. Обёртка над xslt маразм ещё чаще.
Да, молчим, ибо влом писать обыденные вещи.. Для начала: это (<xsl:template match="p">) можно вообще не писать, не то, что писать это (<?match- p ?>) да еще потом парсить. Это всё бред, потому что для начала это (<xsl:template match="p">) можно генерировать автомато. Если ты это не генерируешь автоматом, то скорее всего есть лучшее решение задачи.
и каким образом ты будешь генерировать это автоматом? напишешь искусственный интеллект, который сам будет писать шаблоны? х)
Вообще вы извращенцы что бы XSLT использовать с PHP. XSLT есть смысл использовать когда у вас XML based база данных типа Senda. Вот там да, круто очень. Отправил запрос на базу, а она отдаст сразу XML документ с XSLT трансформациями, CSS и прочими фишками XML. Вот там это совсем другая скорость и абсолютно корректное применение и будет гораздо лучше чем пропускать через PHP. З.Ы. Я 2 месяца вёл спец. курс для нашего гос. архива по XML технологиям, делали обработки на базе их документов. Вот где я познал истинный зэн XML'а. А мешать его части в PHP для шаблонизации глупо - не тот эффект.
спасибо жабажабру... tenshi никто больше не юзал xslt кого я знаю. и когда я впервые с ним столкнулся, почти сразу пришёл к текущему мнению =) а в чём "немаразм"? в чём эффективность
Psih, и что же там глупого? у меня вот например пхп-структура из массивов перегоняется простенькой функцией в хмл и этот хмл в большинстве случаев и отдаётся клиенту для последующего наложения им хслт. в случае поисковиков, рсс-ридеров и мобильных браузеров - это делает сервер. вот umi.cms построена на использовании xml и что-то как-то там особо не жалуются, а даже наоборот. Mr.M.I.T., ты наверно не в тех кругах водишься. плавая в болоте каждая лягушка уверена, что крылья - это бесполезная роскошь. эффективность? да хотябы в том, что хслт получается быстрее смарти и его клонов, даже с учётом времени на формирование dom. или в том, что в нём шаблоны выбираются в зависимости от данных (что даёт большую модульность и реюзинг), в то время как в смарти и его клонах данные выбираются в зависимости от шаблона (что превращает шаблон в эдакий контроллер).
согласен а на кой лягушке крылья? ИМХО, совершенно бесполезная штука. всё равно что знание ассемблера для пользы программирования на пхп. тссс.... (шепотом) там нельзя жаловаться... смарти ближе к сердцу пхп разработчика, даже не смотря на всю его монструозность и бесполезность...
для справки: птицы произошли от рептилий пхпшники большие велосипедисты х) вместо использования стандартных проверенных быстрых гибких средств они с завидным упорством хватаются за свои кривые велосипеды.
tenshi Нормальные PHP'ники знаю что шаблонизатор есть только один - PHP! Всё остальное это уже надстройки - какими бы они небыли. XLST в данном случае тоже надстройка - он вообще из другой области пришёл. XSLT предназначен для работы с XML данными, XML базами, вкупе с XPath и XQuery. Советую w3schools раздел по XML проштудировать от корки до корки и осознать всю охуенность XML и понять, что подвязывать XSLT как шаблонизатор к PHP на все случаи жизни как минимум кощунство! Это случай из пушки по блохам - XSLT слишком крут что бы его привязывать к PHP
Psih, а ещё они знают, что код нужно организовывать исключительно процедурками, а всякие оопы - это надстройки. наличие возможностей стыковать шаблонизатор с различными хмл-технологиями заставляет их все использовать? пхп настолько убог, что недостоин работать с хмл? вот тебе задача: сделать на сайте поддержку atom, rss2 и rss1. как ты её будешь реализовывать?