Иллюзии XML/XSLT технологий

    Иногда в компьютерном мире происходят всплески интереса к той или иной технологии. Всплески не случайные, а явно поддержанные производителями этих технологий. Это и не удивительно, ведь сложно продавать одно и то же, проще продавать что-то новое или старое, но названное иначе. Ничто так хорошо не продается, как функция, которой нет в прошлой модели. Почему так устроен потребитель? А мнение потребителя банально эксплуатируется, ему просто навязывается желание. Крупные производители ПО очень часто исчерпывают рынок сбыта и нуждаются в постоянной смене технологий для того, чтобы продать обновления и просто увеличить цены на программы. Ну и проще отстраиваться от конкурентов, заверяя, что у нас лучшие и новейшие технологии.

    Так случилось с XML. Ведь XML — это, в общем-то, ничего нового. XML — это упрощённое подмножество языка SGML, который берет свое начало еще в GML 1960 года выпуска компании IBM. XML, по сути, просто стандартизировал формат обмена информацией и все.

    Но случилось чудо, мы получили XML и появился объект для рекламы и производители начали на каждом углу заявлять, что у них уже и базы данных с XML и вообще все пропитано XML.

    Да чего далеко заглядывать назад, вот он AJAX и вот он объект для рекламы и продаж. Теперь только ленивый не говорит, что он с AJAX.

    В общем, так устроен мир. Не все новые технологии плохие и не надо их воспринимать в штыки. Но нам нужно уметь выбирать инструменты для тех или иных решений и правильно принимать эти решения для своего бизнеса или решения своих бизнес задач.

    В своей статье «Программирование как искусство» я упоминал уже об увлечении программистов технологической модой. И как я уже говорил, я сам программист и мне и моим коллегам было свойственно увлекаться. И в этой статье я расскажу о наших ошибках связанных с использованием XML/XSLT технологий. Возможно, этот опыт будет кому-то полезен и поможет ему найти правильное место для использования этих технологий. Хотя твердо можно сказать, что эта статья вызовет и большую критику в мой адрес.

    Нашей компанией было разработано несколько программных продуктов. Но первые продукты не нашли большой отклик на рынке, так как содержали ряд технологических и маркетинговых ошибок.

    Один из таких продуктов — «Битрикс: Инфо-портал». Один из самых сложных продуктов, который мы создавали. Разработанный для платформы Microsoft на базе технологий ASP с базой данных MSSQL, он был предназначен для создания веб-решений на платформе MS.

    В первой версии этого продукта (в 1999 или 2000 году, кажется) мы создали свой самописный шаблонизатор, в котором инструкции стояли в правильных тегах и выглядели примерно так #DATA()#. В нем были простые условия и циклы: Ну кто этого не проходил? Да все кто когда-то делал систему, которую предполагалось передать кому-то в использование и настройку, делали свой шаблонизатор.

    После внедрения первых проектов пришла неудовлетворенность таким шаблонизатором. Все время нужно дописывать функции, нужно учить разработчиков своему языку, нет нормальных инструментов отладки и разработки: Ну, в общем, ерунда. Я всегда удивляюсь, когда сейчас еще встречаю продукты, которые используют свои шаблонизаторы. Это как ковыряться в носу пальцем ноги, неудобно и цель не достигаешь. Были варианты использование чужих шаблонизаторов, но это было сменой шила на мыло, мы не приняли этот вариант и пошли искать промышленное решение.

    Действительно, было написано много книг и учебников, в которых программистов и проектировщиков учили, что лучший способ создать шаблонизатор или абстрагировать внешний вид (представление) от данных — это загнать все в XML, пропустить потом через XSLT и уже на выходе получить HTML. Т.е. XSLT и станет для вас лучшим шаблонизатором.

    Утверждалось, что проекты с XSLT шаблонами должны быть проще и удобнее, чем любые другие шаблоны и ими будет удобнее управлять. Много говорилось о безопасности, удобстве переносимости и простоте развития таких проектов.

    Все восприняли это буквально и начали делать подобные продукты. Ну и конечно мы тоже наслушались и уверовали, что наше будущее — это XML/XSLT технологий.

    Совершили подвиг, заставив XSLT шаблоны работать достаточно быстро, вложили кучу сил, времени и денег в разработку технологии… Самые большие каталоги товаров вмещали по 70 тысяч товаров.

    Но клиенты голосовали рублем и внесли ясность.

    Что мы получили в итоге:

    1. Иллюзия простоты XSLT шаблонов.

    Проекты с использованием XML/XSLT оказалось очень тяжело поддерживать клиентам и нашим партнерам. Стоимость владения такими проектами очень велика и имеет тенденцию к росту по мере роста проекта. Специалистов по XSLT очень мало. Технологичный шаблон может подправить только специалист достаточно высокой квалификации. Через XPATH выбирать данные тоже не особенно удобно. Таким образом, развеялась иллюзия, о простоте для клиентов и удобстве в управлении проектами.

    2. Иллюзия управляемости и гибкости.

    Шаблонов XSLT в большинстве своем недостаточно для написания серьезной бизнес-логики в публичной части сайта. Зачем перекладывать серьезную бизнес-логику на шаблон с XSLT? Да так получается в некоторых приложениях, что данные одни и те же, а вот от пользователя или ряда условий зависит, что и в каком виде он увидит. А это уже шаблон и в нем нужна логика. XSLT не развивался как полноценный язык программирования, на нем можно делать только простые условные представления и ограниченную логику. Нет возможности использовать весь потенциал современных языков программирования и библиотек (графика, представление, сервисные функции и т.п.).

    3. Иллюзия производительности, дешевого размещения и масштабируемости.

    Как не стараются РАЗРАБОТЧИКИ, производительность XML/XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей структуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных, получая на выходе опять же текст, который занимает память.

    Реальное решение производительности просматривается только в многоуровневом кешировании, что не всегда возможно, или нежелательно, или просто дорого, как в разработке, так и в использовании.
    Иногда спорят, мол, зачем вам много данных в XML? Ну чтобы сделать шаблон сайта или просто форума, например, на XSLT, в XML должны быть почти все данные: авторизация пользователя, данные по статистике, каталог, ветки товаров или статей: Некоторое решение лежит в области управления и запросе нужных данных в XML прямо из XSLT. Но все равно, данных приходится извлекать заметно больше, условий нужно больше, памяти и запросов приходится делать больше, ну и сам шаблон усложняется и фактически становится уже полноценным программным приложением, что убивает первоначальную цель, сделать шаблон простым.

    Ну и как результат, проекты на этой технологии очень тяжело размещать на обычных хостингах, почти всегда это выделенные машины. Потребность в масштабирование таких проектов возникает довольно быстро и требует значительных финансовых усилий.

    4. Иллюзия удобства абстрагирования данных и внешнего вида.

    Один из плюсов, за которым все гонятся, используя технологии XML/XSLT — добиться качественной абстракции внешнего вида. Но только уже после создания первых шаблонов все понимают, что абстракция получилась, только никому она уже больше не нужна. Шаблон XSLT очень сложен для представления внешнего вида, тем более, современного AJAX приложения. Корректировка такого шаблона требует много сил. Полная смена дизайна требует полного переписывания всех шаблонов, что в расчете на сложность создания XSLT получается еще дороже. Таким образом, получается, что цена владения технологией XML/XSLT очень высока как для разработчиков, так и для их клиентов.

    5. Невозможность создавать библиотеки и повторно использовать результаты работ

    Созданные шаблоны или XSLT приложение нельзя объединить в библиотеку, чтобы уже в следующем шаблоне упросить работу с типовой операцией. Программисты крайне ограничены в передаче своих наработок своим коллегам. Выявленные ошибки приходится отслеживать в нескольких шаблонах.

    6. Нелинейный рост сложности разработки при развитии приложения

    Это действительно странно, но при необходимости динамично развивать приложение, масштабировать его, сложность разработки приложений с XSLT растет совершенно непропорционально получаемому функционалу. Приложения сложно отлаживать. Все это так же приводит к необходимости вовлечения в работу все более квалифицированных программистов.

    И что получается в результате героических усилий разработчиков по освоению технологии?

    Большие расходы на владение и разработку, постоянно возрастающие расходы на масштабирование, низкий спрос на продукты, дорогие услуги, переход в дорогую ценовую группу, уменьшение числа заказов, снижение темпов развития продуктов, отсутствие работающей партнерской сети…

    Значит ли это, что надо вообще отказаться от XML? Конечно, нет. XML/XSLT очень красивая технология (программистская фраза, правда?) и будет еще развиваться. XML отлично работает для связи между проектами (RSS, Яндекс.Маркет, CommerceML и другие). Для небольших шаблонов и фрагментов и сегодня вполне эффективно используется XSLT для обработки XML.

    .NET полностью поддерживает XML во всех его проявлениях. XSLT трансформация тоже поддерживается: если нужно — применяй, не нужно — нет. Но на использовании XML/XSLT никто не настаивает.

    Есть даже очень яркие примеры, когда крупнейшие проекты используют XML/XSLT. Насколько мне известно, Яндекс использует данную комбинацию для своих сервисов. И для меня лучшим результатом эффективности является финансовый результат. Не буду утверждать, но предположу, что себестоимость разработки в отношении к скорости разработки для Яндекса довольно высока, очевидно, в пределах допустимого для данного проекта, но все же не так комфортна, как хотелось бы. Но это только мое предположение. Аналогии с Яндексом я не провожу, это неуместно. Мы делали тиражный продукт, а они делают внутренние сервисы для себя и располагают возможностью использования всех инструментов оптимизации и конфигурирования приложения, обслуживают его только своей командой.

    Конечно, всегда есть соблазн сказать, что выбранный нами MSXML был плох и что есть новые и лучшие парсеры, более оптимальные платформы. Возможно. Но дело не в этом, дело в экономике проекта и в тех причинах, которые я указал выше. В результате мы пришли к выводу, что в тиражном продукте использование XML/XSLT оказалось необоснованно дорого и нецелесообразно.

    Для чего вся эта статья? Выбирайте инструменты обдуманно, не руководствуйтесь только модой и заверением разработчиков технологии о ее невероятной эффективности. Если вы делаете тиражный продукт, как мы, учитывайте экономику партнеров и клиентов. Если для использования продукта разработчику нужно будет знать язык программирования платформы (ASP, JAVA, PHP...) и еще в нагрузку использовать XSLT в шаблонах и XPATH для поиска данных, одно это может сделать проект невыгодным для использования, не говоря уже о массе других причин.

    В общем, голову никто не отменял.
    Поделиться публикацией

    Похожие публикации

    Комментарии 24
      +2
      Используйте тэг habracut, пожалуйста.
        +1
        Спасибо, забыл.
        0
        В общем и целом согласен, хотя 4 и 5 пункты это только ваше имхо, основанное на личном опыте (у меня он диаметрально противоположный). А в общем и целом все укладывается в одну фразу - любая технология/разработка хороша к месту.
        • НЛО прилетело и опубликовало эту надпись здесь
          0
          Некоторые места сильно улыбнули.
          Автор вообще не в теме.
          • НЛО прилетело и опубликовало эту надпись здесь
            0
            Серебряной пули не бывает, и XSLT не является исключением; тут автор прав. А вот пятый пункт ошибочен — code reuse в XSLT наблюдается, и при умелом применении очень даже работает на практике.
              +1
              XSLT это способ несложного преобразования данных. XPath и XSLT - не синонимы. Я как-то переписал систему с XSLT на lxml - скорость возросла на порядок при том что все XPath-запросы остались на месте. А в общем-то правда в том, что всему своё время и место. Например у нас есть код, который порождает XML с данными и они могут преобразовываться в HTML для нормальной версии сайта и в WML для мобильной. Для такой деятельности XSLT подходит идеально. Но этим способом готовится только фрагмент, который вклеивается в нужное место сайта. А сам сайт делается с использованием совсем других шаблонов (ну это наша специфика, не всем нужно отрабатывать сотни QPS).
              0
              А не кажется ли вам, что XML и XSLT предназначены не совсем для того, для чего вы их применяете ? По мне так по меньшей мере странно создавать сайт со сложным динамическим контентом (с AJAX, да даже просто форум) и сложной бизнес-логикой используя набор технологий XML. ИМХО эти технологии в такой задаче не к месту.
              Обработать данные - да, вывести статичную страничку на основе данных - да, в конце концов одна из основных целей XML-XSLT-XPath - работать с структурированными данными, преобразовывать их в функциональном стиле. А генерацию динамичаских сложных страниц не стоит валить в эту кучу.
              Неудивительно, что выбрав хрустальную вазу для забивания гвоздей через некоторое время убеждаешься, что молоток-то удобней. В Вашей статье основная часть описывает больше то, как забивали гвозди хрустальной вазой, и да, действительно неудобно, и куча недостатков. А вот в конце уже правильная мысль - технология должна быть к месту, но лучше задумываться об этом ДО начала создания проекта, "будет ли к месту технология А или Б", а не - "Возьмем технологию А" а через 6 месяцев - "технология А - г.но потому как не помогла нам в проекте".

              А можно задать встречный вопрос - а что вы хотели сказать этой заметкой ? Что серебрянных пуль не бывает ? Я думаю 90% процентов посетителей Хабра это знают, читали Брукса. А дальше-то что ? "Не верьте рекламе" - ну тоже в общем-то Америку не открыли. Если честно - от текста у меня сложилось ощущение в стиле "человек обижен на технологию Х за то, что она не решила его проблемы в области У (хотя технология Х и не предназначена для этого)".
                +1
                Да, я именно и хотел показать, что XML/XSLT желательно использовать именно для простых преобразований. А разве простые преобразования сложно сделать на PHP или ASP? Да нет, так же просто. Тогда вообще зачем в современных программных веб-системах использовать XML/XSLT и вводить в продукты и решения несколько технологий?
                  0
                  Аффтар, вы фееричны. Простые преобразования ага. =) Единственные реальный turing complete язык трансформаций прегоден исключительно для простых трансформаций, и единственный реальный формат обмена данными в SOA вообще не нужен потому что данные в вашем представлении, прошу прощения за тавтологию, представление от содержания отделить нереально. Самое главное что сейчас набегут похапе-кодеры и со всем согласятся.;-)
                    0
                    Удобство, скорость, простота и функциональный подход :). Да и не все, что так легко делается в xslt\xpath, также легко делается в PHP или даже в .NET (а тут еще и компилировать), да и парсер MSXML стоит на почти всех машинах с Windows (с IE6 идет вроде как) - а для PHP- нужен отдельный интерпретатор.
                    Каждая технология занимает свою нишу, и XML\XSLT свою нишу заняли, и плотно.
                    Зачастую XML\XSLT\XPath дополняют монотехнологичные решения, и дают свой выигрыш - в удобстве, в скорости, в гибкости. Если что-то можно сделать со значительно меньшими трудозатратами - почему бы и нет. Монотехнологичность это хорошо, но не это должно быть самоцелью проекта, это просто способ облегчить поддержку, снизить затраты и пр.
                      0
                      что в вашем понимании простые преобразования?
                      имхо, xml+xslt лучше всего использовать при работе с деревьями, притом несимметричными и сложной структурой(молчу уж о возможностях DOM для построения этих деревьев). Берем любой форум. Сколько нужно делать циклов(или рекурсий) чтобы вывести более-менее сложное построение. А с помощью xslt это решается за раз. Тот же смарти требует кодинга циклического вывода.
                      по поводу изменения дизайна: для переноса элементов в правильном построении кода меняется минимум, более того дизайн как правило меняется без изменения каких либо xslt операторов. Достаточно один раз разработать шаблон,дальше изменять его элементарно.
                        0
                        Спасибо за здоровый смех в конце рабочей недели. =) вы фееричны.
                          0
                          А разве простые преобразования сложно сделать на PHP или ASP?
                          Достаньте из HTML определенный div, попутно сделав элементы внутри его неинтерактивными (обнулив атрибут href ссылок, выкосив тэги script совсем, от форм оставив только содержимое) и... хватит даже этого. «На РНР или ASP.» ;)
                          Я не сомневаюсь, что у вас получится — упорства вам, очевидно, не занимать, да вот только насколько поддерживаемо получится? Приведу снова пример. Представьте себе, что этот ваш исходный div лежит на уровень глубже в DOM. Какие изменения в свежеизобретеном велосипеде нужно будет сделать, представляете?
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Грамотный подход, взял на заметку.
                            0
                            а что, cvs-репозиторий яндекса открыт на всеобщее обозрение?
                            0
                            Главная трудность (и она же ценность XSLT) — это нетрадиционный (то бишь функциональный) подход к обработке текста. Многие айтишники затачивают мозг на процедурный подходи (грубо говоря), поэтому эффективно использовать XSLT не получается. Слишком сложная это технология, однако. Но умелая декомпозиция решает все проблемы, но это ой как тяжело.

                            П.С.
                            XPath — фантастически-гениальная вещь :)
                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                > p.s. эх, а что ты чувствуешь, когда начинаешь генерить с помощью XSLT другие XSLT... и появляется желание перейти на третий уровень...

                                Страшно, ага. И увлекательно. И очень легко написать такой кошмар, в котором потом даже самому будет не разобраться.
                              +4
                              Вот, наконец, достойный ответ от представителей лагеря XSLT. Если браться умеючи, то все работает нормально и быстро. И верстается комфортно.
                                0
                                Присоединяюсь ко всем вышевысказавшимся, начавшим комент с фразы "аффтар, вы фееричны". Дремучая некомпетентность.
                                  0
                                  Я думаю что выбор XSLT или шаблонизатор, в стиле Smarty, во многом зависит от того кому в дальнейшем сопровождать и поддерживать продукт. Если таковыми будут люди не слишком привыкшие к сложной логике и структуре данных, то выбор будет за шаблонизатором (Smarty), ну а если проект сопровождают программисты то выбор XSLT будет очень оправдан.

                                  P.S. Все сказанное актуально для web-разработок

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое