Комфортная разработка сайтов на XSL

Первый способ — вызов именованного шаблона, который позволяет работать в том же контексте, но написан в другом месте. Второй способ — применение шаблона к конкретному элементу. Применение шаблона к конкретному элементу или контекстные шаблоны намного лучше именованных тем, что, посмотрев на корневой элемент шаблона, вы всегда понимаете, где вы и от чего считается относительный xpath выражения в вашем шаблоне. Мы всегда работаем с xsl’ем не как с функциональным языком программирования. Мы работаем с декларативным языком, мы описываем шаблоны конкретных элементов дерева, мы всегда работаем с деревом. Понимание того места в дереве, где вы сейчас находитесь, очень важный момент. Быстрота в решении этого вопроса определяет скорость разработки и скорость понимания чужого кода. Контекст и дерево — всё для xsl’я. Не надо изобретать велосипеды и не надо программировать на xsl’е как на JavaScript.

Для web-проекта типичной является ситуация, когда одни и те же данные надо отобразить по-разному на разных страницах. Например, карточка модели в списке моделей, карточка модели на странице самой модели. Это одни и те же данные, но выглядят по-разному. Предположим, сайт разбит на xml’ые страницы. Тогда самый простой способ — для каждого xml’я написать свой собственный xsl, который будет описывать все необходимые для этой страницы шаблоны. И, соответственно, всё легко кастомизируется. Нужно поменять что-то в карточке модели — вы меняете всё, что вам нужно, и это не влияет на другие страницы. Вам не надо об этом заботиться.

Но, разумеется, для каждого web-проекта есть ряд шаблонов, которые используются на всех страницах. Предположим, что шапка и футер используются на всех страницах проекта. Если мы используем для каждого xml’я уникальный xsl, то это превращается в страшную кашу копирования шапок и футеров со страницы на страницу. XSL предоставляет два способа подключения дополнительных шаблонов. Первый из них include. Подключаемые через include шаблоны никак не меняют свою семантику. И второй, более мощный, на наш взгляд способ, это import. Подключая через import, мы имеем уникальную возможность управлять приоритетами подключаемых шаблонов. Шаблоны, подключаемые через import, имеют меньший приоритет, чем те шаблоны, которые описаны в подключаемом файле. Например, в импортируемом файле мы описываем некоторые дефолтные шаблоны для каждой страницы проекта или просто общие шаблоны проекта.

При необходимости в index.xsl, который импортирует в себя main.xsl, мы можем дописать переопределяющие шаблоны. Для того же самого элемента шаблон будет браться из того же самого index.xsl. Таким образом, на каждой странице мы имеем простой способ кастомизировать ее в зависимости от наших потребностей и нужд. Такой подход (когда у вас для каждого xml есть xsl и есть несколько общих шаблонов) решает проблему, когда в xsl’ном шаблоне складывается следующая ситуация: если я на этой странице, то вывожу это, а если я на той странице, то вывожу это, а если я в третьем месте, то будем показывать так. Всю эту логику берёт на себя архитектура ваших шаблонов.

И ещё раз о приоритетах. Меньший приоритет имеют шаблоны, подключаемые через import или расположенные по коду выше. Если вы пишите внизу файла какой-то шаблон, то он заведомо переопределяет написанное раньше. «С менее точным указанием узла, к которому применить» — я не нашла точного перевода этой фразы, поэтому буду объяснять на пальцах. Шаблон для элемента пользователя, user, имеет меньший приоритет, чем для авторизованного пользователя, user [auth]. Предположим, что эта конструкция определяет авторизованного пользователя. Если вам нужно выводить что-то для авторизованного пользователя, такой конструкцией вы переопределяете этот шаблон. И у вас наступает локальное счастье. Ещё один простой способ изменить приоритет шаблона — это явно указать его низкий приоритет. Дефолтный приоритет где-то в районе 0.5-0.25. Если вы указываете отрицательный приоритет, этот шаблон, скорее всего, не применится вообще.

Думаю, многие знакомы с тем, что в xsl’е нет циклов. Кроме того, в xsl’е можно обойтись без условных операторов. Очень часто шаблон состоит из большого условного оператора. Начинаем шаблон, пишем if и поехали, поехали. У нас есть возможность, уточнять область применения шаблона. Например, шаблон для пользователя, который авторизован. Предположим есть дерево, которое говорит, что есть пользователь (user) и он авторизован (auth). Мы его приветствуем «доброе утро», для всех остальных случаев появления элемента user мы просто ничего не делаем. Таки образом мы получили 2 ветви обработки данных, но без использования условного оператора.. Что же в итоге? Во-первых, уменьшается размер самого шаблона, а во-вторых, такие вещи обрабатываются на порядок быстрее, чем условные операторы. Если в xsl начинаются проблемы с производительностью, обратитесь к этим конструкциям. Я думаю, часть проблем будет решена. Если сначала вы выкинули два слеша, то в последствии можно оптимизировать условные операторы.

Таким же образом можно заменить оператор choose. Например, мы захотели выводить форму авторизации для неавторизованного пользователя, а авторизованному пользователю — сказать «доброе утро». Тогда очень просто добавляется третий, четвёртый, пятый случай интерпретации элемента user на странице. Естественно, оператор choose нужно просто разделить на много маленьких шаблонов. При необходимости вы можете переопределить каждый конкретный случай вывода информации о пользователе, не копируя весь блок целиком. Если бы был только один шаблон для элемента user, то понадобилось бы копировать всю логику в другой файл и менять маленький кусок. Такая модульная структура позволяет переопределить только небольшой фрагмент. А там оставить: пусть оно там живёт, кушать не просит.

Все форумы для начинающих в FAQ объясняют, что переопределить переменную нельзя. Однако это можно сделать с помощью приоритетов. Если в импортируемом шаблоне определена некоторая переменная, то в основном шаблоне можно присвоить этой переменной новое значение. Такое же правило с переопределением работает для именованных шаблонов: они так же переопределяются. Ключи не переопределяются, а join’ятся, то есть они все складываются и получается один большой ключ. User set атрибуты тоже не переопределяются, а дополняются. Я вам рекомендую посмотреть правило в спецификации. Это была часть о приёмах, которые делают код читаемым и более структурированным.

Я хотела бы остановиться на редакторах, которые существенно упрощают жизнь xsl разработчика. Мой любимый редактор XMLSpy. Может быть, кто-то не разделяет моего мнения, но я считаю, что ранние версии XMLSpy решали все мои проблемы как разработчика. Ничего больше мне было не нужно, валиация по схеме мне никогда не была нужна в практической работе. Многие мои коллеги пользуются JEdit. Это бесплатная альтернатива, которая работает на Java. Из-за этого JEdit немного тормозит.

Некоторые мои коллеги используют Far с плагинами. Смотреть на это, конечно, невозможно, потому что на дворе 21 век, а у них синее окошко. Но одни из самых производительных наших разработчиков почему-то используют Far с плагинами. Не знаю, почему.

Последнее время стал популярным редактор IDEA. Люди, которые работали с Java или какими-то другими языками в ней, в ней же работают с xsl. Я не знаю, насколько это удобно, но люди работают.

И последний маргинальный вариант: люди, которые работают в Vim с xsl каждый день. Я использую Vim. Мне можно, я уже начальник и не каждый день много пишу. Это лучший способ зайти на удалённый сервер, что-то поправить или что-то скопировать. Подключаться по SAMBA бывает очень дорого и противно, монтировать диски тоже отнимает время. Проще придти на любую машину и воспользоваться Vim’ом. В Vim’е есть подсветка синтаксиса, есть банальный auto complete. Он, конечно, не учитывает всего словаря xsl, но, по крайней мере, из того, что уже написано, подставляет. Этого вполне достаточно. Единственная проблема — приходится запускать xmllint, чтобы проверить, получился ли вообще xml.

XSL-процессоры или XSLT-процессоры. Сложное название. В компании «Яндекс» мы используем libxslt в связке с libxml2. Сейчас на продакшене 12 версия. Он не падает, работает быстро и, кроме всего прочего, имеет режим --profile, который позволяет посмотреть, какие шаблоны на самом деле были выполнены, сколько времени это заняло. Это очень удобно для профилирования больших систем. Действительно, перед запуском мы садимся и выясняем, что и где так долго думает. В течение приблизительно нескольких дней производительность увеличивается раза в два. У других процессоров я такого режима, к сожалению, не встречала. Есть ещё несколько вещей. Например, в Saxon уже есть поддержка XSLT 2.0. Xalan хорош своей поддержкой схемы. У меня не было опыта работы с Microsoft технологиями. 4xslt, к сожалению, я тоже не видела.

И ещё одно дополнение, позволяющее сделать нашу жизнь намного проще. Это набор расширений с exslt.org. Я рекомендую всем, кто работает с xsl сходить туда и посмотреть, вдруг вы можете это применить. Чаще всего используется расширение, которое облегчает работу с датами. Мы уже забыли, что такое выводить название месяца из его номера через условие: что если номер один, то январь, а если номер два, то февраль. Там есть математика, в том числе случайные числа, которые очень часто требуются в разработке Web-ресурсов. Там есть преобразование строки в дерево. При решении некоторых задач очень хочется иметь преобразовать, получаемую строку в дерево. Стандартными средствами XSLT 1.0 это сделать невозможно. У Microsoft есть собственное расширение под это, но мы пользуемся exslt.org. Там много полезных функций для работы со строками, это tokenize, replace, split, перекодировки. Есть библиотека регулярных выражений. Регулярные выражения, конечно, можно использовать в xsl’е, но мы стараемся придерживаться правила, что xsl для работы с деревьями, а не для работы со строками. Поэтому если возникает задача, когда необходимо строчку разобрать регулярным выражением, собрать, сделать ещё 38 преобразований, пойдите лучше к тому разработчику, который вам выдал такой xml, настучите ему по чему-нибудь, и пусть сам это делает. Поддержка регулярных выражений в Java и Perl на порядок лучше, чем в xsl. Никакая сторонняя библиотека не обеспечит той точности разбора и той скорости, которая нужна. Не разбирайте xsl в строки, это плохо. Можно, но плохо. Exslt.org предоставляет как бинарные (то есть xslt расширение поддерживается на уровне исходных кодов в некоторых xslt процессорах, в частности в Linxml), так и некоторые расширения в виде xsl шаблонов. Например, работу со сроками вполне можно реализовать на xsl. Чтобы не писать самому разбор строки, можно взять оттуда. В общем, не изобретайте велосипеды, используйте библиотеки и переопределяйте то, что вам мешает или то, что вам нужно изменить. Использование библиотек при разработке xsl оправданный подход. И мы используем ряд собственных написанных библиотек. После стабилизации они не требуют поддержки. Они хорошо работают и дают простор для творчества. Из того, что есть у нас и что интересно общественности. Пару лет назад мы написали поддержку xforms на xsl. Ряд наших проектов, в том числе проект «Яндекс-Деньги», использует описание форм в формате xforms, потом xsl’ем мы трансформируем в html. Можно подумать о том, чтобы обнародовать библиотеку. Она, возможно, кому-то будет полезна. Кроме того, мы используем один пейджер на всех xsl проектах, хотя многие из нас периодически хотят написать свой пейджер. Но используем мы только один. Есть еще несколько кросс-проектных элементов интерфейса, например, формы авторизации, блог информации за логином. Я не думаю, что вам будет это интересно. А exslt.org это, собственно, сайт. В общем, всё.

Вопрос: У нас порядка 1000 файлов xslt, мы выделили слои, а проблема заключается в том, что управлять этими слоями очень трудно. Есть ли способ визуализации большого количества фалов и зависимости между ними?

Надежда: Мы периодически пробовали решить эту проблему, потому что она у нас возникала. Никаких автоматов, которые бы позволили это сделать, мы не нашли. Я даже пару раз писала свои xsl, которые приблизительно это делают. Но из-за того, что мы очень часто используем шаблоны по умолчанию, мы сталкиваемся с тем, что, не зная дерева, с которым работают эти xsl, понять, что от чего зависит, невозможно. Поэтому единственным способом понять, какие шаблоны были применены, это собственно режим профайлинга. xsltproc --profile и поехали, реальность такая. К сожалению, с отладкой возникают проблемы. Но если писать так, как мы рекомендуем, мелкими шаблонами, то эта проблема стоит не так остро.

Вопрос: В начале доклада прозвучал такой тезис, что xslt следует использовать только в том случае, если данные на сайте собираются из каких-то разрозненных источников в формате xml. Если же данные формируются все на одном сайте, то использование xslt не оправдано. Почему?

Надежда: В случае приложений, написанных на Java, для которых мало хороших, удобных шаблонных движков, тогда, действительно, можно использовать xsl, хотя всё генерируется java’ой. А когда все данные генерируются Perl’ом или PHP, для которых есть хорошие шаблонные движки, обладающие всей необходимой функциональностью, какой смысл генерировать дерево, потом в этом же процессе вызывать xsl, чтобы получить html.

Вопрос: Это практически то же самое, когда привлекается другой шаблонный движок, который парсит какой-то вывод?

Надежда: Использовать можно, но не надо использовать xsl ради xsl. Это неудобно, потому что из Perl вы не видите всего xml, который есть. xml это файл, плюс туда приходят какие-то данные по протоколу http. Вы их можете просмотреть глазами, и это удобно. Чтобы вывести xml, который у вас получился, в Perl, придётся совершить ещё некоторое количество движений. При написании xsl вам всегда надо видеть xml, на который вы накладываете.

Вопрос: Предположим, он есть, этот xml, но он не физический. Он формируется, его описание, его структура всегда доступны.

Надежда: xsl, разумеется, можно использовать в Perl.

Вопрос: Я рассматриваю в контексте PHP.

Надежда: Для PHP есть удобные шаблонизаторы. Я считаю, что xsl это шаблонизатор, поэтому какой смысл делать лишний шаг преобразования структур данных, массивов или ещё чего-то в xml, чтобы потом на него наложить xsl. В принципе, xsl немного дороже по производительности, чем шаблонный движок. Особого смысла нет.

Вопрос: А на сколько он?

Надежда: Я никогда не мерила PHP с xsl, у меня не было практической задачи.

Вопрос: Вы упомянули дополнительную функцию exslt в качестве одной из. Мне кажется, эта функция основная. Это возможность преобразования строки в дерево, если я правильно понимаю, речь идёт о функции nodeset. Дело в том, что наличие этой функции, в частности, для нас, является основным фактором использования xslt. Цепочное многократное xslt преобразование. Я знаю, что во многих FAQ пишут, что это не нужно. И, тем не менее, не могли бы вы сказать, используете ли вы такую технику и поддерживаете ли вы её? То есть цепочное xslt преобразование.

Надежда: Мы непрерывно используем цепочное xslt преобразование, без этого у нас не получается большой проект. И для нас функция nodeset — это ключевая функция многих решений, в частности, xforms, которые мы написали. Они невозможны без построения промежуточных деревьев. Простые сайты получаются без вспомогательных деревьев, сложные нет. И я не вижу ничего плохого в том, чтобы построить дополнительное дерево. Просто не надо, чтобы это дерево было огромным и копировало то, что у вас уже есть.

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

Вопрос: Что мешает делать цепочку преобразования на Perl? Там это ещё проще.

Вопрос: Цепочное преобразование на Perl будет Mapping структур данных, Perl to Perl.

Надежда: А чем плох Perl to Perl?

Вопрос: Этот mapping должен выполнять программист.

Надежда: Да, но программист тоже должен работать. Да два года назад я считала, что xslt forever и мы переведём весь «Яндекс» на xslt. Но потом почему-то это всё прошло. Я согласилась с тем, что у нас есть разработчики, которые пишут Perl’овые шаблоны. Потом оказалось что разработчики, которые пишут Perl’овые шаблоны, так же легко пишут xsl и наоборот. Поэтому мы теперь счастливы, и у нас полная демократия в этой области.

Вопрос: У меня два вопроса. Первый: вы сказали, что у вас используется Perl, а дальше идёт xslt. А что дальше? Apache получает преобразованную страничку, кто собирает, грубо говоря, из xml?

Надежда: Связку Perl-xml-xsl мы широко не используем, потому что пару лет назад, когда мы решили это попробовать, всё текло по памяти. Для проекта «pda.yandex.ru», для наладонников как раз применена схема Perl-xml-xsl. Там Perl зовёт поиск как источник по http, получает из него xml, вызывает из него xslt шаблоны и даёт это наружу. Мы не используем никакой mod-xsl. CGI скрипт выполняет всё необходимое, но это не высоко нагруженный проект. Если бы это был высоконагруженный, мы бы сделали по-другому.

Вопрос: Второй вопрос: если у вас какой-то проект начинается с нуля, естественно, xml получить невозможно, пока программист его не напишет. Получается, пока нет xml, xslt сидит, отдыхает. И как вы решаете эту проблему?

Надежда: Я придерживаюсь правила: пока нет данных и дизайна, мы вообще ничего не делаем. Мы можем только разговаривать с разработчиком, какой xml нам удобен. Мы ничего не делаем, пока нет xml с данными. Обрабатывает формы серверное приложение, а потом оно отдаёт результаты в формате xml. У нас есть библиотека, позволяющая делать redirect из xsl, то есть мы анализируем работы формы и отправляем пользователю либо спасибо, вы молодцы, либо всё плохо.

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

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

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