Иногда в компьютерном мире наблюдаются всплески интереса к той или иной технологии.
Скачки не случайны, а явно поддерживаются производителями этих технологий.
Это неудивительно, ведь продать одно и то же сложно; проще продать что-то новое или старое, но с другим названием.
Ничто не продается лучше, чем функция, которой не было в предыдущей модели.
Почему потребитель структурирован таким образом? А мнение потребителя просто эксплуатируется, ему просто навязывают желание.
Крупные производители программного обеспечения очень часто истощают рынок и им необходимо постоянно менять технологии, чтобы продавать обновления и просто повышать цены на программы.
Что ж, легче отличиться от конкурентов, убедившись, что у нас есть лучшие и новейшие технологии.
Именно это произошло с XML. В конце концов, в XML нет ничего нового.
XML — это упрощенное подмножество языка.
СГМЛ , который восходит к IBM GML 1960 года.
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 для поиска данных, то одно это может сделать проект нерентабельным для использования, не говоря уже о много других причин.
В общем, голову никто не отменял.
Теги: #xml #xslt #xpath #движки шаблонов #Разработка веб-сайтов #xml
-
Прикладная Психология
19 Oct, 24 -
Крутая Gif-Анимация
19 Oct, 24 -
.Mastername Упрощает Аукцион Доменов
19 Oct, 24 -
2G И 3G: Старикам Не Место?
19 Oct, 24 -
Рождественские Развлечения С Google Maps
19 Oct, 24 -
Истоки Мотивации В Agile И Scrum-Менеджменте
19 Oct, 24 -
Работа С Сенсорным Экраном На Arduino Due
19 Oct, 24
