Появление модуля Блогов в нашем продукте, это отличный повод опубликовать материал. 
Действительно, было написано много книг и учебников, в которых программистов и проектировщиков учили, что единственный способ абстрагировать внешний вид
(представление) от данных - это загнать все в XML, пропустить потом через XSLT и уже на выходе получить HTML.
Утверждалось, что проекты c XSLT шаблонами должны быть проще и удобнее, чем любые другие шаблоны и ими будет удобнее управлять. Много говорилось об удобстве переносимости и простоте развития таких проектов.
Все восприняли это буквально и начали делать подобные продукты. Не скрою, мы тоже были в рядах сторонников этой технологии и выпустили на рынок продукт
"Битрикс: Инфо-портал" разработанный на ASP+MSSQL+XML+XSLT.
Совершили подвиг, заставив XSLT шаблоны работать достаточно быстро, вложили кучу сил, времени и денег в разработку технологии... Самые большие каталоги товаров вмещали по 70 тысяч товаров.
Но клиенты голосовали рублем и внесли ясность.
Что мы получили в итоге:
1. Иллюзия простоты XSLT шаблонов.
Проекты на XML+XSLT очень тяжело поддерживать клиентам. Специалистов по XSLT очень мало. Технологичный шаблон может подправить только специалист очень высокой квалификации. Таким образом, развеялась иллюзия, о простоте для клиентов и удобстве в управлении.
2. Иллюзия управляемости и гибкости.
Шаблонов XSLT в большинстве своем недостаточно для написания серьезной бизнес логики в публичной части сайта. XSLT не дорос до полноценного языка программирования, на нем можно делать только простые условные представления и очень ограниченную логику. Нет возможности использовать все возможности современных языков программирования и библиотек (графика, представление, сервисные функции и т.п.)
3. Иллюзия производительности, дешевого размещения и масштабируемости.
Как не стараются разработчики, производительность XML+XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей архитектуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных получая на выходе опять же текст, который занимает память.
Реальное решение производительности просматривается только в многоуровневом кэшировании, что не всегда возможно, или нежелательно.
Ну и как результат, проекты на этой технологии очень тяжело хостить, почти всегда это выделенные машины. Потребность в масштабирование таких проектов возникает уже начиная с 1000-10000 уникальных пользователей в день и требует значительных финансовых усилий.
4. Иллюзия удобства абстрагирования данных и внешнего вида.
Один из плюсов, за которым все гонятся, используя технологии XML+XSLT - добиться качественной абстракции внешнего вида. Но только уже после создания первых шаблонов все понимают, что абстракция получилась, только никому она уже больше не нужна. Шаблон XSLT очень сложен для представления внешнего вида. Корректива его требует много сил. Полная смена дизайна требует полного переписывания всех шаблонов, что в расчете на сложность создания XSLT получается еще дороже. Таким образом, получается, что цена владения технологией XML+XSLT очень высока как для разработчиков, так и для их клиентов.
Это только некоторые моменты...
И что получается в результате героических усилий разработчиков по освоению технологии?
Большие расходы на владение и разработку, постоянно возрастающие расходы на масштабирование, низкий спрос на продукты, дорогие услуги, переход в дорогую ценовую группу, уменьшение числа заказов, снижение темпов развития продуктов, отсутствие работающей партнерской сети...
Значит ли это, что надо вообще отказаться от XML? Конечно нет. XML+XSLT очень красивая технология и будет еще развиваться. XML отлично работает для связи между проектами (RSS 2.0, Яндекс.Маркет, CommerceML и другие). Для небольших шаблонов и фрагментов и сегодня вполне эффективно используется XSLT для обработки XML.
Можно ли добиться абстрагирования продукта от дизайна и бизнес-логики другим способом, отличным от XML+XSLT? Конечно, возможно. В своем продукте
"Битрикс: Управление сайтом" мы это сделали. Причем сумели даже создать технологию обновлений SiteUpdate, которая в нормальной реализации встречается вообще крайне редко и возможна только при полном разделении внешнего вида и бизнес-логики приложений:
http://www.bitrixsoft.ru/sitemanager/siteupdate.php
Тема интересная и говорить о ней можно долго
При случае, продолжу...
Кстати на КИБе Лёха Андреев, по-моему, упоминал Drupal в своем докладе как движок-прототип для сообществ будущего.
Любопытно было бы сравнить оба движка для постройки блог-сообществ, если бы Сергей нашел время для комментария - признательность!
А пока "пошел" тестировать блог от Битрикса - надеюсь, будет удобно и приятно работать с ним!
2. Шаблонизатор, в роли которого можно применять XSLT, по определению не является языком программирования и не предназначен для таких задач, как работа с графикой, обработка данных и пр. Возможности же имеет смысл обсуждать на конкретных примерах в сравнении с другими решениями.
3. Существующие реализации технологии сравнительно ресурсоёмкие и производительность XPath оставляет желать лучшего, согласен, но откуда огромные массивы данных в вебе, где каждая страничка от силы 100 килобайт?
4. А при использовании других шаблонизаторов полная смена дизайна не требует полного переписывания всех шаблонов? Шаблоны типовых элементов, например, списка страниц, запросто поддаются повторному использованию.
По поводу битрикса... Ребят вы как стреляли из пушки по воробьям так и стреляете!
Когда Сергей Рыжиков говорит о xslt как о языке программирования ... меня просто в дрожь бросает... а знает ли он о чем вообще говорит?
Чтобы идти своим путем, совсем не нужно доказывать, что чужой путь ошибочный.
Докажите всем, и в первую очередь, самому себе, что вы правильно рассуждаете и ваша точка зрения позволяет вам заработать денег.
2. Совершенно не собираюсь кого то тыкать носом и показывать куда нужно топать... не благодарное дело
3. Позволяет заработать денег!P:)
Довольно сложно изложить ряд вещей. Можно придраться к формуле XSLT - язык программирования... но это как раз и была образная попытка сказать, что его недостаточно для ряда вещей где он нужен бывает...
Я уже не раз получил сходные отклики на свое суждение от людей, которые делали большие проекты.
Это не исключительная и не абсолютная точка зрения. Я не утверждаю, что применять этот опыт надо везде и всегда. Но это опыт и тот, кто делает проекты, может его учесть.
Удачи вам в ваших проектах
точнее сказать, многие путают вьюху с шаблоном и пытаются в шаблоне реализовать всю логику отображения, в результате чего получая монстра на любом языке в том числе и на xslt.
правильный шаблон должен выражать выходной формат документа и только это.
"Но только уже после создания первых шаблонов все понимают, что абстракция получилась, только никому она уже больше не нужна. Шаблон XSLT очень сложен для представления внешнего вида. Корректива его требует много сил. Полная смена дизайна требует полного переписывания всех шаблонов, что в расчете на сложность создания XSLT получается еще дороже. Таким образом, получается, что цена владения технологией XML+XSLT очень высока как для разработчиков, так и для их клиентов. "
Вот это вообще ни о чём. Конкретики нет, автор явно ниразу не верстал менюшку какую нить на xslt.
Вот у меня, например, цмска на xslt работает. Сделать с нуля типовой бизнесс-сайт для меня - вопрос 2 дней максимум. Спасибо шаблонам xslt, развёрстанным год назад. А если ещё и цсс грамотно подключить...
Если не жалко, дайте посмотреть на примеры сайтов и шаблоны, как вы их генерите.
И у вас XSLT работает на клиентской или серверной стороне?
Тоесть у Вас клиенты сами правят HTML и шаблоны?
Бедные клиенты.
>Специалистов по XSLT очень мало.
Смотря в какой ценовой категории. Среди проф. верстальщиков специалистов по XSLT довольно много, тем более XSLT - родная для верстальщика технология (XML, как и XHTML), а вот изучать какой-нибудь очередной доморощенный шаблонизатор (причем разный для каждого проекта) ему врядли понравится.
Хотя судя по "This page is not Valid HTML 4.01 Transitional!: Failed validation, 671 Errors", возможно у нас с Вами разные представления о верстальщиках.
>2. Иллюзия управляемости и гибкости. (..текст проскипан..)
Господин хороший, XSLT это _НЕ_ язык программирования. Это язык _ПРЕОБРАЗОВАНИЯ_.
Это шаблонизатор. Вся его логика должна ограничиватся выбором между красненькой (если поле равно "off") или синенькой (если поле равно "on") кнопочкой.
Если у Вас в ШАБЛОНАХ БИЗНЕС ЛОГИКА - Вам нужно срочно читать Фаулера, или хотя бы про MVC.
Если у Вас в шаблонах работа с графикой, обращения к базе и мат. расчеты - то читать нужно еще срочнее.
>Сначала данные из SQL базы преобразуются в XML
Современные БД (к примеру MS-SQL) прекрасно возвращают SQL данные, а современные платформы (.NET например) преобразуют результаты любого SQL (ADO.NET DataSet например) в XML.
>а это текстовый файл большого размера в силу своей архитектуры
"в силу своей архитектуры" XML это ДЕРЕВО. Оно может НИКОГДА не превратится в текст. Если Вы создаете дерево через DOM, а потом натравляете на его XSLT, то ввиде "текста с тагами" оно никогда не появится. Или Вы думаете что процессоры XML хранят данные ввиде строки текста?
> Далее XSLT проходит по огромному массиву данных
У Вас для каждой страницы выбирается "огромный массив данных"? Не понял, Вы всю базу в XML дампите что ли?
>очень тяжело хостить, почти всегда это выделенные машины.
Да, за все надо платить.
>только никому она уже больше не нужна.
Когда дизайнер меняет внешний вид сайта, кто в Вашей комманде натягивает на сайт новый шаблон?
Программист?
>Шаблон XSLT очень сложен для представления внешнего вида.
Пожалуйста, приведите пример внешнего представления, которое тяжело реализовать с помощью XSLT.
>Корректива его требует много сил
Полагаю меньше, чем корректива программного кода.
Тем более это работа верстальщика, а не программиста, а для верстальщика это родная стихия
>Полная смена дизайна требует полного переписывания всех шаблонов
Расскажите про это вот этим ребятам: http://www.csszengarden.com/
>Значит ли это, что надо вообще отказаться от XML?
Странная логика. XSLT это примерно 0.1% того, для чего нужен XML.
>XML отлично работает для связи между проектами
...и для многого другого
>Для небольших шаблонов и фрагментов и сегодня вполне эффективно используется XSLT для обработки XML.
Да, для таких небольших как http://market.yandex.ru/
> В своем продукте
>"Битрикс: Управление сайтом" мы это сделали.
Позвольте полюбопытствовать - как?
Дай-ка догадаюсь: Вы разработали... свой шаблонизатор! Он намного быстрее, проще для изучения, имеет богатые функции для работы с картинками, и специалистов по нему пруд-пруди
Верно?
И эти люди запрещают мне ковыряться в носу (с)
Ничуть не мешаем, продолжайте спокойно, не обращайте на наши заблуждения внимания.
Я поделился с вами опытом, который мы получили делая проекты с использованием XML+XSLT. Я не раз общался с компаниями, которые получили сходный опыт и это были большие и известные проекты и это убедило меня, что стоит опубликовать эту информацию.
Мы набили шишки и честно рассказали вам, что мы делали и что получили. По моему мнению, этот опыт применим как к тиражным продуктам, так и к целому ряду индивидуальных проектов. И чем дольше предполагается цикл жизни проекта или продукта, и чем сложнее этот проект и продукт, тем я бы советовал внимательнее прочитать мое сообщение. Досадно будет испытав все потом на своем опыте и заплатив свои деньги за ошибки. Я надеюсь, что кому-то наш опыт поможет избежать ошибок или быть более корректными и внимательным в выборе или использовании технологии.
Но вы вправе полностью игнорировать мою точку зрения и не сообщать мне об этом
А вы как рьяные евангелисты уперлись в фразу что я назвал XSLT языком программирования и опровергаете это очевидное упрощение. Да не важно это все. Смысл статьи не в этом. И досадно, я не вижу комментариев про деньги, т.е. про себестоимость владения, про ваш реальный опыт внедрения и поддержки проектов на этой технологии. Со мной спорят программисты, убеждения которых я затронул. Извините ребята, но я уже
не про технологии, я говорю про деньги и про долгосрочную перспективу.
Выбор за вами. Всегда за вами. Вам решать и определять какие инструменты использовать. Учитесь только не на своих ошибках, так как это просто очень дорого
Вы взяли компьютер, и попытались открыть им консервную банку. У Вас это не получилось.
Но я могу ошибатся.
Пожалуйста, ответьте мне вопросы:
> у Вас клиенты сами правят HTML и шаблоны?
>почему у Вас для каждой страницы выбирается "огромный массив данных"
> Когда дизайнер меняет внешний вид сайта, кто в Вашей комманде натягивает на сайт новый шаблон?
> Программист?
Спасибо.
Если, к примеру, все веб-приложение состоит из одного файла DoAll.php, то наши подходы настолько различны, что я физически не смогу применить Ваш опыт.
Вот именно что бы понять Ваш подход, я и задал эти вопросы.
Ну не в этой же теме и не с таким настроением
Я не понял эту фразу.
Да.
Это общее утверждение. В шаблоне может понадобиться много данных и их приходится заранее готовить и складывать в XML или нужно запрашивать дополнительные данные, что обычно замедляет работу. Чтобы через XSLT шаблон вывести, например, прайс лист в зависимости от прав пользователя (колоночный прайс), необходимо в XML засунуть информацию о пользователе, каталог товаров с правами по группам, иногда нужна информация по группам, может понадобиться информация о доступных сервисах пользователя, ну и сами сервисы. Опять же постраничка уже идет по сформированному XML массиву данных. И очень запросто получается, что размер XML будет большим.
Безусловно, будут частные случаи, когда данных будет немного, XSLT шаблон будет простым, править его будет просто. Но в сложных компонентах и при усложнении логики, сложность XSLT шаблона и ресурсоемкость будут увеличиваться непропорционально быстро.
> Программист?
ИТ специалист. Это широкое понятие. у нас большой процент клиентов внедряют решение сами, не имея профессиональных разработчиков.
Редко дизайнеры сами верстают. Вообще по жизни
>Да.
В таком случае XSLT и правда не лучший вариант.
Клиенты, полагаю, используют для верстки автоматизированные средства, такие как Front Page, либо же написанный вами WYSIWYG редактор, верно?
XSLT же расчитан на опытного верстальщика.
>Чтобы через XSLT шаблон вывести, например, прайс лист в зависимости от прав пользователя >(колоночный прайс), необходимо в XML засунуть информацию о пользователе, каталог товаров с >правами по группам
Не совсем понятно почему не сделать это на уровне бизнес-логики.
XSLT мог бы получить только готовые к выводу данные.
Это было бы правильно.
>Наш шаблон всяко проще верстать чем XSLT, если вы это хотите выяснить.
Для тех, кто "внедряют решение сами, не имея профессиональных разработчиков" - безусловно.
Я выяснил все, что хотел.
Спасибо!
Клиенты, полагаю, используют для верстки автоматизированные средства, такие как Front Page, либо же написанный вами WYSIWYG редактор, верно?
XSLT же расчитан на опытного верстальщика.
HTML правят в визуальном редакторе, это понятно. А шаблоны сайта или компонент редко так правят. Обычно это не только HTML, но и вывод переменных и условия. Так что тут правят как любые шаблоны в привычных каждому инструментах.
XSLT мог бы получить только готовые к выводу данные.
Это было бы правильно.
Варианты вывода бывают разные. Правильно конечно через бизнес логику и так и делается, обычно.
Но на одной бизнес логике бывает много разных шаблонов, которые к тому же еще могут зависеть (выводиться по разному) от прав пользователя. Так что данные приходится зачастую лишние засовывать в XML в расчете на более сложные шаблоны.
Странно звучит
Или настоящий профессионал не ищет простых путей!
http://www.1c-bitrix.ru/blog/rsv/220.php (ссылка по теме)
Вот этого-то я и не знал!
Я понимаю, что написать визуальный редактор для XSLT довольно не просто
Дело в том, что большинство серьезных проектов имеют профессионального верстальщика, который верстает шаблоны вручную. Просто потому, что ему нужно:
1) сделать код максимально соответствующий сложному дизайну
2) сделать сайт быстро грузящимся
3) сделать сайт, который отображается во всех браузерах.
Попробуйте сверстать в визуальном редакторе http://yandex.ru/ например)
Все что может делать клиент - вводить данные в спец. области в сайте, но ни в коем случае не менять HTML.
>Но на одной бизнес логике бывает много разных шаблонов, которые к тому же еще могут зависеть (выводиться по разному) от прав пользователя
Обычно для этого в бизнес-логике вводится понятие "пользователь" и его "права", тогда этим начинает заниматся бизнес-логика, а не уровень представления.
Шаблон это всего лишь инфа о том, как и что где-то отображается.
Именно по этому XSLT так чудно подходит для этих задач.
Если же вы делаете в уровне представления какие-то действия (например проверяете права пользователя или ищите простые числа) то XSLT в таких задачах уступает языкам программирования.
Есть такая проверка качества разделения системы на слои: можно ли что нибудь хакнуть через шаблоны уровня представления. Если нельзя (все что можно сделать - вывести данные) - значит разделение соответствует современным паттернам проектирования, если хакнуть можно (например показать непредназначенные данные, или завалить сервер, или удалить файл) - значит система современным паттернам не соответствует.
>Странно звучит Кто непрофессионал, тому типа легче. А почему тогда профессионалу сложнее?
Не совсем. Просто профессионал может быстрее и лучше сделать вручную то, что непрофессионал может делать только с помощью спец. утилит.
Проф. верстальщик версает вручную, далекий от верстки человек - в визуальных редакторах.
Проф. дизайнер рисует, далекий от графики человек использует готовые клипарты.
итд
Я так понимаю, что Ваш продукт расчитан именно на такого вот простого человека.
В визуальном редакторе для яндекса пишутся новости и весь контент.
Шаблоны смешанные с кодом не правит никто кроме программистов на яндексе. Я так думаю
Именно по этому XSLT так чудно подходит для этих задач.
Ну конечно. Но вы слегка теоретизируете. Вы все увидите на практике.
В общем да, мы делаем все, чтобы сделать сайт управляемым для не технических специалистов.
Сайтом должен управлять тот, кто знает для чего пишется текст и кто умеет работать с аудиторией.
А я думаю, что смешанных с кодом шаблонов у яндекса нет. По крайней мере в новых проектах. Там используют XSLT (это мне известно наверняка
>Сайтом должен управлять тот, кто знает для чего пишется текст и кто умеет работать с аудиторией.
Не спорю. Но на мой взгляд он должен подготавливать тексты, и передавать их тех. специалисту, так как только он сможет красиво и правильно разместить их на сайте.
Но все конечно зависит от того, какого эффекта Вы хотите добится.
Некоторые граждане стараются сделать html максимально чистым и правильным.
Они просто не могут позволить себе вставлять <br /> после каждой строчки.
Они так же не хотят что бы с отключенным картинкам их сайтом было невозможно пользоватся.
Они-то используют проф. верстальщиков.
Есть и другие. Будет ли сайт весить на 5 кило больше чем нужно, будет ли он немного неправильно отображатся в IE 5.0 или при отключении картинок - им все равно.
Большинство пользователей все равно ничего не заметит.
Им, конечно, нет смысла тратится на верстальщика. Вполне подойдет визуальный редактор
Еще как может быть. Не прямой код, а "код" XSLT условий и циклов.
Небольшой пример из XSLT шаблона:
<xsl:for-each select="/Bitrix/OfferList/rs:data/z:row">
<ПакетПредложений>
<xsl:if test="$EXTENDED='Y'">
<xsl:attribute name="ID"><xsl:value-of select="@ID"/></xsl:attribute>
</xsl:if>
<xsl:if test="not(@NEW_INFO) or @NEW_INFO='Y'">
<xsl:attribute name="ИдентификаторКаталога"><xsl:value-of select="@CATALOG_XML_ID"/></xsl:attribute>
<xsl:attribute name="Владелец"><xsl:value-of select="@XML_ID"/></xsl:attribute>
<xsl:if test="@DATE_START">
<xsl:attribute name="ДействительноС"><xsl:value-of select="substring-before(@DATE_START, 'T')"/></xsl:attribute>
</xsl:if>
<xsl:if test="@DATE_END">
<xsl:attribute name="ДействительноДо"><xsl:value-of select="substring-before(@DATE_END, 'T')"/></xsl:attribute>
</xsl:if>
<xsl:attribute name="Описание"><xsl:value-of select="@DESCRIPTION"/></xsl:attribute>
<xsl:attribute name="Валюта"><xsl:value-of select="@CURRENCY"/></xsl:attribute>
<xsl:if test="$EXTENDED='Y'">
<xsl:attribute name="DESCRIPTION_TYPE"><xsl:value-of select="@DESCRIPTION_TYPE"/></xsl:attribute>
<xsl:attribute name="SORT"><xsl:value-of select="@SORT"/></xsl:attribute>
<xsl:attribute name="NAME"><xsl:value-of select="@NAME"/></xsl:attribute>
<xsl:attribute name="VISIBLE"><xsl:value-of select="@VISIBLE"/></xsl:attribute>
<xsl:attribute name="OFFER_LIST_PRICE_TYPE"><xsl:value-of select="@PRICE_TYPE"/></xsl:attribute>
</xsl:if>
</xsl:if>
<xsl:variable name="OLID" select="@ID"/>
<xsl:for-each select="key('o', $OLID)">
<Предложение>
<xsl:if test="$EXTENDED='Y'">
<xsl:attribute name="ID"><xsl:value-of select="@ID"/></xsl:attribute>
</xsl:if>
<xsl:if test="not(@NEW_INFO) or @NEW_INFO='Y'">
<xsl:attribute name="ИдентификаторТовара"><xsl:value-of select="@PRODUCT_XML_ID"/></xsl:attribute>
<xsl:attribute name="Цена"><xsl:value-of select="@PRICE"/></xsl:attribute>
<xsl:attribute name="НормаУпаковки"><xsl:value-of select="@RATIO"/></xsl:attribute>
<xsl:attribute name="Количество"><xsl:value-of select="@AMOUNT"/></xsl:attribute>
<xsl:attribute name="Единица"><xsl:value-of select="@UNIT"/></xsl:attribute>
<xsl:attribute name="Валюта"><xsl:value-of select="@CURRENCY"/></xsl:attribute>
<xsl:variable name="OFID" select="@ID"/>
<xsl:for-each select="key('opv', $OFID)">
<ЗначениеСвойства>
<xsl:attribute name="ИдентификаторКаталога"><xsl:value-of select="@CATALOG_XML_ID"/></xsl:attribute>
<xsl:attribute name="ИдентификаторСвойства"><xsl:value-of select="@XML_ID"/></xsl:attribute>
<xsl:attribute name="Значение"><xsl:value-of select="@PROPERTY_VALUE"/></xsl:attribute>
</ЗначениеСвойства>
</xsl:for-each>
</xsl:if>
</Предложение>
</xsl:for-each>
<xsl:if test="not(@NEW_INFO) or @NEW_INFO='Y'">
<xsl:if test="not($EXTENDED) or $EXTENDED != 'Y'">
<ЗначениеСвойства>
<xsl:attribute name="ИдентификаторКаталога"><xsl:value-of select="@CATALOG_XML_ID"/></xsl:attribute>
<xsl:attribute name="ИдентификаторСвойства">OFFER_LIST_PRICE_TYPE</xsl:attribute>
<xsl:attribute name="Значение"><xsl:value-of select="@PRICE_TYPE"/></xsl:attribute>
</ЗначениеСвойства>
</xsl:if>
<xsl:for-each select="/Bitrix/OfferListRefPropertyValue/rs:data/z:row[@OFFER_LIST_ID=$OLID]">
<ЗначениеСвойства>
<xsl:attribute name="ИдентификаторКаталога"><xsl:value-of select="@CATALOG_XML_ID"/></xsl:attribute>
<xsl:attribute name="ИдентификаторСвойства"><xsl:value-of select="@XML_ID"/></xsl:attribute>
<xsl:attribute name="Значение"><xsl:value-of select="@PROPERTY_VALUE"/></xsl:attribute>
</ЗначениеСвойства>
</xsl:for-each>
</xsl:if>
</ПакетПредложений>
</xsl:for-each>
...
С таким шаблоном будет работать только разработчик. Да и ему удовольствие ниже среднего.
Мало таких. В основной массе сайты управляются просто подготовленными пользователями, но никак не программистами или верстальщиками.
- Расставить отступы (я уверен, что изначально оно и было сделано)
- Преобразовать <xsl:attribute name=""><xsl:value-of select=""/></xsl:attribute> в <xsl:attribute name="" select=""/>. А можно еще и прямо так: <node attr="{$var}">
- Вынести часть for-each в отдельные шаблоны.
Работать с таким шаблоном - все равно что с программой написаной в одну строчку. Поэтому логичен вопрос: этот шаблон был сгенерен автоматически?
и где именно используется там XSLT
насколько я смог понять -- то там на серверной стороне происходит обработка (правда, непонятно, зачем тогда файлы называтся *.xml) и клиенту выдается уже готовый html (притом, видно, давно все это разрабатывалось, а то верстка мусорная и табличная).
Спасибо.
1. Битрикс - это аналог лапши БП, только не для еды, а для разработки веб решений.
2. Профессиональным разработчикам надо держаться подальше от Битрикс, что они и делают судя по ссылкам на партнёров.
3. Больше никогда не буду писать в интернете о чём-то, в чём я ничего не соображаю, иначе будет очень стыдно и может нанести вред имиджу компании, в которой я работаю(руковожу).
4. Спасибо за этот пост, теперь есть страница, где всё уже расписано и понятно.
Ну и отлично, Дима! Ваш кругозор стал шире, вы обзавелись новой полезной страницей
Я, например, именно потому ее нашел, что уже набил свои шишки и пытаюсь понять, почему.
Спасибо большое, что делитесь с нами опытом.
Если вас не затруднит, вопрос:
насколько я понял, вы разочаровались в XSLT для темплейтинга НА СЕРВЕРНОЙ стороне.
но касается ли решение и преобразования на клиентской стороне? (когда вы генерите только xHTML, а браузер строит представление на основе XSLT)
Спасибо.
но касается ли решение и преобразования на клиентской стороне? (когда вы генерите только xHTML, а браузер строит представление на основе XSLT)
Мне кажется, принципиально ничего не изменится, добавиться только букет проблем несовместимости браузеров в клиентской части исполнения и ограничения на версии возможных браузеров.
потратил вчера много часов на тестирование-изучение.
Больше всего понравися труд http://www.xmlplease.com/xsltcases-xhtml2txt
но даже он при исполнении на клиентской части выполнился в Опере и ФФ, но НЕвыполнился в IE6 и Chrome
жаль, что парсеры так криво работают.
Если бы они выполняли свою функцию -- наверное такой темплейтинг был бы действительно самым лучьшим.
В будущем, может так и будет:
CMS генерит типовой XHTML, в котором только вызывается /templates/index.xsl
в последнем же будет все преобразования верстки и подключения css, вместе они даддут свободу верстальщикам натягивать любой дизайн на движок в одном целостном и стандартизированном файле.
Но это только теория, на практике не все популярные браузеры даже просто выполняют типовые преобразования.
Как вариант еще возможно, ч то кто-то вложит огромный труд на разработку xslt-хаков, как это было в свое время с кросбраузерностью верстки и javascript.
кому интересно, файлы моего тестирования здесь
http://kauroff.com/work/testing/xslt/index.xml
http://kauroff.com/work/testing/xslt/.../index.xsl
Тогда это было модно на западе, а заказчик был оттуда и сайт был простой - решили рискнуть в проекте. Хотя задача была выполнена и далее сайт просто поддерживался, ощущения остались одназначны как и у Вас - плюсы на практике не понятны, трудоемкость неадекватно высокая.
С тех пор только в одном проекте вижу толк от XSLT, где он используеться для я бы назвал human readable отображения XML документов, которыми обмениваються системы. Ключевой на мой взгляд проблеммой являеться как раз то, что как тут пишут XSLT - язык преобразования. Меня лично не учили в ВУЗе что это такое, тока программированию
XSLT здесь отлично реализует задачу, гораздо лучше и удобнее разбора на PHP.