XML: свет в конце туннеля
DL
19.6.2001
В январе я написал на тему классов шаблонов. В ответ мне настоятельно порекомендовали изучить XML и XSL, и не прошло и полгода, как я попробовал таки работать с XML.
Первое, что предлагают желающим? это функции парсинга XML. Я спросил работающий пример. Код своего xml-парсера мне прислал Михаил Владимиров (автор сайта "How IT works"). Принцип работы этих функций такой: вы пишете функцию, например, для тегов, открывающих контейнер ? <font> ? функция start_elem, которая определяет, на что заменить данный тег. Сообщаете php, что именно её надо использовать для обработки XML, а php, скомпилировав код, будет вызывать её сам. Сама функция состоит из одной большой конструкции "switch $tag { ... case ... }". Мне такое не очень понравилось (наверное, я бы проще ориентироватлся в своём шаблоне). Я спросил, нет ли чего более удобного. "Используй Sablotron, там всё цивильно." ? ответил мне Михаил.
Sablotron ? это XML-процессор, который из XML-документа и таблицы стилей XSLT (это не как CSS, а набор специальных тегов) делает документ любой разметки, какой пожелаете (можно даже текстовый файл сделать). Просто берёте и пишете XML-документ, используя удобную вам разметку, а затем для этой структуры пишете XSLT. XML можно формировать скриптом динамически, а можно опять же через шаблоны. Думаю, что если я в скором времени переделаю этот сайт под Sablotron, от шаблонов по-прежнему не откажусь. Лень мне два раза в разных файлах написать один и тот же SQL-запрос. Пользовался когда-то FastTemplate, но слишком глупое это занятие объявлять в разных скриптах одни и те же блоки, поэтому я написал свой собственный класс, который считывает запросы из самих же шаблонов. А типовые схемы XSLT можно сохранить в файлы. В скрипте вызывается обработчик XML+XSLT и результат его работы выдаётся пользователю. Никаких проблем с совместимостью броузеров, XSLT, как и PHP хранится только на сервере (читал где-то вариант работы с XML, где он разбирается на компьютере у пользователя при помощи яваскрипта ? но это же маразм!).
Содержимое отделено от его представления. Давняя мечта программиста. В принципе, ничего нового по сравнению с классами шаблонов нет ? те же места вставки переменных или дочерних шаблонов, те же блоки строк, однако это прорыв. Прорыв по следующм причинам:
1. Обработчик шаблонов ? бинарная программа, она не компилируется при каждом запуске скрипта, а постоянно сидит в памяти, причём в одном экземпляре (если php установлен как модуль).
2. Sablotron ? программа с открытым кодом, и поэтому в ней (по идее) должно быть меньше багов на килобайт кода, чем в самопальном классе.
3. Стандарт XSLT един для всех людей на планете.
4. Консоль Sablotron-а может внятно сообщить о возникшей ошибке, значит отлаживать XSLT гораздо проще.
Недостатки XML+XSLT есть, и для маленьких проектов они могут даже перевесить достоинства.
1. Ещё один язык разметки, который надо изучить (на самом деле, не так уж сложно)
2. Ещё один модуль в архитектуре сервера. Больше времени на настройку, больше багов.
3. Фривар ? это никакой гарантии работоспособности.
4. Да, кстати! Отлаживать схемы XSLT можно только на саблотроновской консоли ? сервер будет просто говорить "Fatal error in line #n".
Из очень полезного в данной схеме работы ? значительно проще реализовать разные варианты представления данных, проще говоря скины. Если на сайте есть неколько типов страниц (как на этом), приходится разделять шаблоны на уровни. Один ? для всего сайта, содержит таблицу стилей, шапку страницы, служебную информацию. А вот в колонке где сейчас вы видите текст, может быть информация совершенно другой структуры. Под каждую структуру свой файл с шаблоном. В каждом скрипте (разумеется, их количество близко к количеству этих самых структур данных) выбирается нужный шаблон второго уровня. На этом сайте файлов шаблонов всего 14. Плюс к тому часть шаблонов лежит в базе данных. С файлами можно изловчитсья и разделить их, скажем, на директории. А как быть с заготовками в базе? Вводить дополнительные поля? Или держать в одном и разделять спецсимволами? В общем, чтобы сделать несколько видов страницы, придётся сильно попотеть.
Вспоминаю, как в конце 99-го года я думал, как сделать на своём сайте выбор цветовой схемы ? как в WebClub.ru ? и прикидывал, как лучше объявлять переменные для разных цветов и как найти и заменить все цвета в странице. Разумеется, выбор цвета я тогда не сделал, не сделал и сейчас, хотя и подумывал.
В этом плане XSLT значительно упрощает жизнь. Если типовые страницы не сильно отличаются друг от друга (например, как на "php в деталях"), можно ограничиться одним XSLT-файлом для всего скина. Тогда будет гораздо проще реализовать выбор скина для броузера или цветовой схемы.
Дизайнеры могут смело редактировать XSLT, не боясь испортить вам ? программистам ? php-код. Так же отныне такую вещь как подсветка строк то белым то серым цветом можно спихнуть на XSLT ? в описании есть пример. Если номер строки нужен только ради самого себя, нумерацию строк тоже можно отдать обработчику. Операции "если есть такая-то значение, вывести её с таким обрамлением" забываем ? на это есть кострукция "<xsl:if", а мы можем думать о более глобальных проблемах.
Я сознательно не стал давать рекомендации, где применять XML и XSLT. Так же я не стал давать в тексте примеров кода. Я лишь постарался описать видимые удобства и недостатки этой схемы обработки данных, потому что более детально рассказывать не позволяет совесть ? слишком мало знаю. Результаты моих опытов и ссылки на документацию прилагаются.
