Комментарии 99
данные хранились в xml: удобно быстро редактировать и заливать обновления
при импорте xml разбивается на куски и помещается в базу: для того что бы делать постраничный вывод записей
при отображении rowset преобразовывался обратно в xml методом asXml: получаем часть большого xml файла, то есть срез, и работаем с ним xslt преобразованием
из этого xml делалась локализованная часть веб отображения (html) а также rss экспорт
резюмирую:
- исходник xml (ориентировочно "немаленький")
- в базе он разбивается на записи, но с расчётом на то что можно будет получить его срез
- срезы с помощью xslt преобразовываются в разные представления, а именно несколько html представлений и rss
никаких сложностей. разве-что, из-за js, т.к. все работает через ajax.
... и как заметил denver, переменные определять можно, и передавать в templates(только в именованый) как параметры, а вот возвращать - по-моему нельзя.
Стоит почитать, что делает технология XML/XSLT/xPath, но пытаться запомнить синтаксис не стоит. Точнее не стоит уделять этому особое внимание.
Итог: стоит прочитать быстренько. Страниц 200 за выходной бахнуть, чтобы понимать "мощность" технологии, но сильно в подробности не стоит вдаваться до тех пор, пока нет на чем попрактиковаться.
Практически весь html код сайта, начиная то меню сайта и заканчивая новостными лентами. Генерируется распарсиванием xml`а средствами xslt.
Практически весь html код сайта, начиная то меню сайта и заканчивая новостными лентами. Генерируется распарсиванием xml`а средствами xslt.
Удобно.
В случае если выдавать на парсинг браузеру, то не совсем понятно как на это посмотрят поисковики.
По нагрузке: если страницы можно кэшировать - вшистко едно. Если же при каждом показе трансформировать - то при большой нагрузке будет заметно медленней чем шаблонизатор попроще. Хотя если перекидывать избирательно на клиента, то быть может XSLT даже выгодней будет (ведь IE + FF это львиная доля).
Мне кажется что серверные XSLT-парсеры пока не особо оптимизированы (что, тем не менее, не фатально и можно использовать то что есть). Имхо со временем чаша производительности должна измениться в сторону XSLT. Так что я думаю привыкать можно смело.
За разный контент разным посетителям сайта можно по шапке получить от гугла.
Общем пока что мое мнение такое, что для веб программинга не стоит юзать XSLT. Нет смысла генерить XML потом XSLT преобразует в HTML. Мне кажется XSLT придуман и подходит для обработки данных из XML где нибудь на сервере для каких то второстепенных нужд. Типа лежит файлик с данными, совсем несложно написать XSLT шаблон чтобы превратить во что то другое.
Хотел немного добавить. Согласен, что генерить XML, а потом его обрабатывать XSLT неправильно. Использовать XSLT стоит, когда у тебя уже есть сгенерированных XML - например, ты получил его от другого сайта. Тогда другое дело. Но самому генерировать XML, забирая контент, например, из базы, а потом его преобразовывать XSLT глупо.
Сейчас есть всякие RSS и т.п. - вот место для XSLT (тут ты не знаешь, когда будет сгенерирована новая версия XML, поэтому и не можешь ее хранить в базе).
Если же ты сам генерируешь XML и XSLT, то еще не пришло время, когда можно отсылать клиенту XML, чтобы он сам его преобразовывал с помощью XSLT. Но все к этому идет, как мне кажется.
Возможно имеет смысл хранить постоянную информацию в виде XML, а потом ее преобразовывать в XHTML с помощью XSLT, когда у тебя объем XML файлов очень большой, а используется каждый в отдельности очень редко. Иначе тогда выгоднее хранить инфу в базе - ведь из нее быстрее вытянуть, чем из файловой системы.
Ну а генерировать контент в разных форматах чем вам мешает использование обычных шаблонизаторов? Покрайней мере гемора будет намного меньше. Попробуйте нагенерить на XSLT что нить посложнее... голова лопнет
В любом случае надо добавлять в скрипты возможность парсить документ нужным шаблоном.
MySQL -> XML -> HTML|PDF|etc. Зачем это лишнее звено (XML) если можно сразу генерить
HTML?. Если сделаете бенчмарк, то увидите как медленно генерится XML. Потом посмотрите как долго происходит XSL трансформация. И сравните с тем, если бы этого звена небыло.
Тут есть смысл юзать его если необходимо на выходе иметь XML (Например RSS либо API), или XML по каким то другим причинам замешан в этом деле. Например feedburner отдает XML и дает на парсинг браузеру ещё и XSL шаблон. Тогда RSS выглядит на странице как им это надо а не как сделано в браузере.
Для обычных вебсайтов мне кажется это неосознанный ход как минимум из соображений производительности (в крайнем случае пока не все браузеры могут распознавать). Ну а если уже и отдаешь браузеру эту работу, то с поисковиками непонятно как дело обстоит.
мое мнение такое, что для веб программинга не стоит юзать XSLT. Нет смысла генерить XML потом XSLT преобразует в HTML.
Я пожалуй добавлю ваш коммент в избранное и поставлю ремайндер на "через 1 год". Там посмотрим :)
У вас предубеждения, а я делал сравнение темплейт систем. Не смотря на то что нужно генерировать XML нельзя сказаь что весь процесс был медленней на порядок. Всего-то раза в два. И то, бОльшая часть была из-за медленного парсера Sablotron. Так что не стоит так брезгливо смотреть на это, некоторые уже используют.
А вот обрабатывать большой XML файл (однажды сгенерированный из базы) с помощью XSLT это точно перебор. Просто очень медленно по сравнению с SQL->XML->XSLT->HTML.
А на сервере сфантазировать что-нибудь, кеширование там какое или ещё что.
Только вот гемморно это. Вот весь мой OnRails, сколько из-за трудоемкости разработки xslt, которая в большинстве случаев не оправдывает полученной универсальности. Плюс обязательное преобразование в xhtml, сложности с обработкой пользовательского ввода и сущностей и и прочих.
Шаблоны получаются слишком избыточными xslt кодом.
Скорее всего вы прийдете к такому же мнению.
А насчет вида шаблона. Избыточный плохое слово, код-то достаточный. А вот непривычно что так много - это да. Но разве у остальных шаблонизаторов будет меньше? Да, у тех что и по функционалу попроще (и соответственно с отделением представления от бизнес логики). И потом, кому это мешает если есть специалисты верстальщики которые понимают XSLT? Если же их у вас нет, то тогда, конечно, неприятно.
В такой ситуации видимо xml+xslt - единственный выход.
Для обычных же сайтов (как верно замечено выше) - все это довольно избыточно. Шаблонизацию можно устроить намного проще.
"возможность максимально отвязать код от дизайна" :)) смешно,
думаю ЭТО никогда нельзя будет "отвызать" ... либо кодерам хоть чучуть верстать уметь, либо верстальщикам чучуть додить, т.к. комнтрукции , , , и т.п. все-таки юзать приходится :)
У меня CMS-ка выдает все в XML-формате а перед выдачей всей страницы пользователю она парситься XSL-шаблоном.
Насчет геммороя - не соглашусь. Раньше делал шаблоны в коде, т.к. было лень использовать XML. Однако, потратив пару месяцев на освоение xslt полностью на него перешел и возвращаться обратно не собираюсь.
Да, код получаеться избыточным. Однако, когда шаблонизатор "видит" весь материал в одном результирующем XML-дереве то появляються просто невероятные возможности для формирования конечного XHTML-документа.
Вообщем, всем советую.
CMS-ка собственная, написана на Parser.
Идея использования XSLT, показавшаяся вначале сумасшедшей, оказалась идеальным решением, отделив данные с которыми работает PHP+MySQL от их графического представления.
Несколько ограничений было замечено, но все обошли малой кровью.
Самое важное - оставить возможность обработки на сервере, ибо некоторые действия с XSLT подвешивают IE и подобные трансформации лучше делать на сервере, передавая готовый HTML
Конечно, лучший шаблонизатор...
Первый опыт был с формой контракта. Пользователь заполнял поля, данные, по мере набора, в xml отправлялись на сервер, где лежали 2 шаблона (html + xslt). Трансформация подхватывала данные и расставляла их "по местам" в html-шаблон (доступ к которому имели дизайнеры, не разбиравшиеся в xslt, но этого им было и не нужно). Результирующий html возвращался пользователю в качестве preview контракта... удобно всем — и разработчикам (нас никто не трогает — изменения в форме контракта не требуют изменения кода, поменяли html-шаблон и делов) и дизайнерам (не нужно ничего кодить) и менеджменту...
Продолжением стала работа с формами InfoPath из комплекта MS Office. Там xslt используется как основополагающий инструмент построения отображения. Идея проста, как три копейки — данные (xml-файл) могут быть представлены разными видами (xslt) плюс иметь бизнес-логику в codebehind (C#, JScript) и отображаться встроенным компонентом InternetExplorer. При этом визуальный редактор позволяет накидать дизайн этих видов очень быстро...
Сейчас формы InfoPath с помощью OfficeServer адаптируются для тонких клиентов - перекочёвывают в веб. И здесь мы столкнулись с одной небольшой проблемой. Десктопное приложение поддерживает dataset'овы дифграммы, а web-версия не хочет. Так вот, спомощью xslt на сервере преобразуем получаемые от клиента данные в diffgram, и dataset их "кушает" за милую душу!
Ну и напоследок хочу сказать о производительности. Был у меня один проект... xml-слепок таблиц базы данных, собираемый из нескольких источников, список литературы, с кучей атрибутов... xml файл весил чуть больше 8 мегабайт. Требовалось выдавать пользователю постраничный вид, отсортированный и отфильтрованый по любым из атрибутов. Проблема была в том, что данные были несколько неоднородны. Решили попробовать xslt. И не прогадали — построение вида было довольно быстрым — трансформация перелопачивала весь файл за считанные секунды (особенно, когда его в кэш загнали :)... так и работает до сих пор :-)
Поскольку пишем под ASP.NET то парсером является msxml.
Кстати, в 2005 студии появилась возможность дебагать xslt прямо из C#-кода, а msxml позволяет включать в трансформацию скрипты JavaScript, C# и VB, что очень помогает для реализации, например, таких вещей, как хранение переменных. В упомянутом diffgam-преобразователе замечательно используются Generic коллекция :-)
Плюсы следующие:
1. Это стандарт. Значит, можно менять и расширять штат верстальщиков, не заботясь об известных им форматах хранения шаблонов - читай "языков программирования". Ситуация, когда приходится править вёрстку, вернее, вносить изменения внутри запрограммированного шаблона - довольно частая.
2. Поддержка именованных и параметризованных блоков в шаблонах. Smarty и erb заставляют эти блоки держать в отдельных файлах.
3. Генерация валидного (X)HTML.
Минусы:
1. Не слишком удобный декларативный синтаксис. Скажем, если генерируется список option'ов, конструкция, прописывающая аттрибут "selected" на XSLT выглядит гораздо длиннее, чем на erb.
2. В XSLT 1.0 мало функций. Вывод русской даты стандартными средствами - целый геморрой, хотя, конкретно в PHP можно вызвать внешнюю PHP-функцию. Тут и проявляются "прелести" синтаксиса.
3. Оверхед:
- Нужно прописывать DTD, заголовки, подгружать описания HTML-сущностей и
так далее.
- Данные приходится преобразовывать из формата языка программирования в
XML: эта операция создаёт избыточность внутри конкретного скрипта - одни
и те же данные приходится держать в переменных скрипта (выборка из базы)
и в XML.
4. Отсутствие конечных циклов (изменить $i от 1 до 3). Требуется, скажем, для генерации номеров страниц в постраничной навигации.
5. Не особенно удобно делать шаблоны текстовых писем (xml:space="preserve"): за переносами следить сложнее чем в случае шаблона на PHP. Аннонят конструкции вроде: " Здравствуйте! ... (тут перенос)... ".
6. XPath не позволяет делать некоторые типы выборок. К сожалению, не могу привести конкретный пример, но я с этим время от времени сталкиваюсь.
7. Что спорно и решаемо - скорость работы.
минусы:
1. что тут сложного и долгого?
<xsl:template match="input" mode="form">
<xsl:element name="{name()}">
<xsl:if test="@selected = true">
<xsl:attribute name="selected">selected</xsl:attribute>
</xsl:if>
<xsl:value-of select="." />
</xsl:element>
</xsl:template>
2. так вроде совсем просто
<my-date year="2007" month="2" day="12" />
<xml-months>
<month>января</month>
<month>февреля</month>
<month>марта</month>
...
</xml-months>
<xsl:value-of select="//xml-months/*[position() = //my-date/@month]/text()" />
3. все тривиально
а) один раз прописать
б) делайте хоть echo(), а в ob() вызовите обработчик
4. может я не понял, но чем вам рекурсивный вызов шаблонов с параметрами
не нравится? в них и проводите инкремент
5. странно
<xsl:text>
</xsl:text>
6. ???
7. поспорю
Скажем, вместо конструкции из пункта 1 мне удобнее написать:
<select name="..."><?= generate_options($options, $selected); ?></select>
Это короче, понятнее и быстрее работает.
То же с конечными циклами: вряд ли кто-то согласится заменить конструкцию for на рекурсивную функцию в C++. В XSLT рекурсивные шаблоны - не удобное, а вынужденное решение, workaround.
<xsl:value-of select="myfunctions:generate_options($options, $selected)/>
Ещё проще и понятнее :-)
<select name="..."><?= generate_options($options, $selected); ?></select>
против
<select name="..."><xsl:value-of select="php:generate_options($options, $selected)/></select>
:)
Я не против XSLT, использую его почти во всех проектах. Лишь попытался описать минусы. Читаемость и писаемость :) всё же оставляют желать лушего. Я слышал что-то про краткий синтаксис, но не копал глубоко.
И написать шаблон по обработке данных, что в $options, и не нужно городить тут функции пользователя для работы, с которой XSLT справится лучше.
<xsl:variable name="options" select="/root/options"/>
<xsl:apply-templates select="$options">
<xsl:with-param name="selected" value="/root/currentOption"/>
</xsl:apply-templates>
<xsl:template match="options/row">
<option value="{id}"><xsl:if test="$selected=current()/id">
<xsl:attribute name="selected">yes</xsl:attribute>
<xsl:value-of select="value"/>
</option>
</xsl:template>
Запись достаточно громоздкая. Я ещё раз повторяю, XSLT - эффективный инструмент, но его синтаксис в приложении к языку шаблонов сайта мог бы быть проще.
Это простой пример, попробуйте привести пример вывода древовидного меню с открытой текущей ветвью, преимущества XSLT будут видны сразу.
Да и мешать PHP с версткой не очень хорошая затея. В XSLT получается безопасный код для сервера, можно поручить составлять шаблоны и не бояться что туда вставят нежелательный код.
Результатами голосования опечален. Я думал, что хабра-пипл - более продвинутый контингент. А 40% просто не знакомы с этой технологией. (Те 33% которые ответили строго "НЕТ" видимо знакомы поверхностно.) Весьма печально.
Использую xml/xsl повсеместно. Результатом работы практически любого моего php-скрипта/java-сервлета является xml-документ. xml/xsl - отличный инструмент расслоения системы на layer'ы document/view.
По фразе "я использую xml/xsl в качестве шаблонизатора", можно понять, что человек уже знаком как минимум с одним php/java/python/...-шаблонизатором и ошибочно употребляет слово шаблонизатор в этом контексте.
Я принципиально против использования любых шаблонизаторов (не xslt-процессоров). Есть стандартизованый протокол документа и стандартизованый протокол преобразования. Незачем изголяться и придумывать каждый раз что-то новое.
Вы используете XSLT в веб проектах?