XML + XSLT: ещё раз о специализации программных средств
DL
28.8.2001
На днях на выпуск об XML мне написал свой отзыв человек с ником вЪедливый. Мы решили продолжить обсуждение, и хочу дать ответ на [] в форум.
У xml xsl есть много подводных камней. Грамотно использовать его может лишь уже поднаторевший в этом.
(лирическое отступление? попробуйте поискать {Fatal error: Call, Warning: MySql} в яндексе. Результаты просто поразительны. И после этого вы будете всех перетаскивать на xml xsl ?).
1. Создавать xsl шаблоны ? это изучение верстальщиками еще одного языка. Это для программиста новый язык ? новый роман, верстальщикам сложнее.
2. Дополнительные трудности по написанию в строгом синтаксисе чтобы xml был валидным (кавычки, регистр, слэш на одинарных тагах, закрывать параграф, когда наконец все проги будут понимать русские название элементов и аттрибутов ???)
3. Выдавать xml на php сложнее чем html. На больших проектах это существенно замедляет отладку.
4. Уродская ситуация с xml и русским языком. Примерно такая же как была в jave на заре развития. Хотя конечно принципиально поддержка разных языков продумана, но новичков отпугивают первоначальные сложности. Каждая новая прога начинает с игнорирования всего кроме ascii и utf8. Php "Supported target encodings are ISO-8859-1, US-ASCII and UTF-8". Конечно это не проблема для тех кто уже почуствовал запах xml.
5. Создавать html на лету по xsl это ресурсоемко. Есть принципиальные проблемы с буферированием и получением лишь части xml. Пусть нам нужно выдать большую страницу полученную по большому xml (условно xml ? 1 Мб). Придется загрузить ВЕСЬ xml трансформировать и выдать ВЕСЬ ответ зараз. Без xml мы можем читать файл частями и выдавать по мере прочтения а не все сразу. С xml придется использовать SAX парсер ? опять доп трудности.
6. Вместе с xml все равно необходим скриптовый язык. Простейший пример ? показать N символов текста node, причем N выбирает клиент (т.е. N параметр представления а не структуры), счетчики (цифры либо буквы). Php либо jscript либо ... Кстати xml любит раздувать конструкции xsl
<div>
<xsl:attribute name = "id"><xsl:value-of select = "lev"/></xsl:attribute>
<xsl:attribute name = "class">t<xsl:value-of select = "deep"/></xsl:attribute>
<a><xsl:attribute name = "href">javascript:f('<xsl:value-of select = "lev"/>')</xsl:attribute><img border="0" align="top"><xsl:attribute name = "src">p<xsl:value-of select = "deep"/>.gif</xsl:attribute><xsl:attribute name = "name"><xsl:value-of select = "lev"/></xsl:attribute></img> <xsl:value-of select = "title"/></a>
</div>
<?php
echo <<<CONF
<div id=$lev class=t$deep>
<a href=javascript:f('$lev')><img border=0 align=top src=p$deep.gif> $title </a>
</div>
CONF;
Что из этого проще и понятнее ? Это я еще не сравнивал <xsl:if> <xsl:foreach> и if и foreach или for.
7. Трудности по загонке данных в xml. Например при экспорте в xml из excel я столкнулся с проблемой с символами ® ©. Кроме того xml создан для написания структурированных документов. Даже в ворде не все способны создавать структурированные документы. А сколько человек работают с tex который так же создан для создания структурированных документов?
Примечание. Я использую xml в своей работе. Просто иногда цена за использование xml выше чем отдача от него. Поравьте меня если ошибся. Жду возражений дополнений
И наконец самое главное
8. Ни одна база данных не поддерживает xml на нормальном уровне (мб Оracle9i XMLType ?). XML существует на начальном уровне хранения в виде файлов. Конкретнее нужно чтобы: База данных индексировала xml и позволяла быстро выдернуть часть дерева в естественном для xml синтаксисе не просматривая все. Причем желательно чтобы в случае если xml содержит ссылки на др xml то из них тоже выдиралась лишь необходимая часть. Позволяла заменить/вставить целую часть дерева за раз. Хочется смотреть на базу не как на совокупность плоских таблиц а один иерархический документ. (а лучше обоими способами).
Конечно мы можем хранить xml в clob и blob и т.д. а отдельные элементы, атрибут вытаскивать в поля, но это ИЗВРАТ.
Это нарушение изначальной концепции ? МЕДЛЕННЫЙ (как и положено интерпретатору) php использует быструю написанную на C базу данных для вычленения НЕБОЛЬШИХ кусочков информации, на обработку которых у него хватает сил.
Складываестя впечатление, что мы говорим на разных языках. Особое удивление вызывают пункты 6 и 8. Никто не предлагает заменить языки скриптования XML-ем. Это разделение труда и специализация. Тебе же не придёт в голову придумывать свои форматы записи больших объемов данных, если есть база? Ответ по пунктам приведу ниже, потому что это не самое главное.
Твоя схема работы на подключаемых файлах с верхом, низом страницы и действиями вроде записи логов, конечно удобна на проектах разного масштаба. Но она косвенно ограничивает функциональность сайта. По своему опыту знаю: с увеличением функциональности (например, сделать шапку страницы с подсветкой текущей позиции, сделать там динамические меню, которые появляются не везде и т.п.) начинается путаница. И ладно, если только ты и работаешь над таким проектом. Куда хуже будет, если такой чужой проект дадут тебе или если над ним работают двое. А если смена дизайна всего сайта, что делать? Сидеть и ковырять код? Класс шаблона тоже не очень спасает. Как мне и предсказывали, на сложном проекте я тону в тегах. Верстальщику работать с шаблонами тоже неудобно.
Об XML говорят много, и преимущественно ничего ? пустые фразы. "Отделение контента от дизайна" (или "данных от их представления") превратилось в ничего не значащее заклинание.
Работа с XML позволяет, во-первых, иметь дело в программе только с данными, во-вторых, работать с ними как с []. Вполне естественно, что за это надо платить увеличением ресурсоёмкости. А вот писать код валидно, в строгом синтаксие ? это не проблема, а вопрос культуры производства. Php-скрипт ты же пишешь по всем правилам.
Применение XSLT для трансформации XML в HTML облегчает работу программиста тем, что XSLT как специфический язык программирования берёт на себя такую мелочёвку как подсветку строк через одну, нумерацию списков и многочисленные if?else, необходимые только для правильного вывода информации (например, подсветка в меню навигации текущего места).
Связка XML+ XSLT избавляет тебя, программиста, от такой мелкой рутины и позволяет заняться только обработкой данных (при этом убрав из кода, с которым работаешь, весь шум вёрстки). Она требует большей квалификации от верстальщика и/или дизайнера, но зато теперь они не только придумывают формат документов, но сами и воплощают его в реальность. Больше верстальщик не будет бегать к тебе с просьбой: "Надо, чтоб у нового анонса значок мигал." Теперь он сам этим занимается и не морочит тебе голову этой дурью. :) Ты можешь заняться высшими материями.
В конце концов, тебе самому проще будет работать с чётко разделёнными узлами: здесь данные, здесь их обработка, здесь их форматирование. При смене дизайна сайта не надо будет хвататься за голову от того, что придётся вручную перебрать все скрипты. В мае дорожники положили новый асфальт, в июне жилищники стали ковырять теплотрассу. Теперь же конфликты задач упразднены. Теплотрасса лежит в другом измерении.
Разумеется, применять или не применять XML+XSLT ? это личное дело. Просто поражает подход многих людей, которые не попробовали, а заранее говорят: "да нафига нам это?!", "что там такого особенного?!".
Подводя итог, скажу: php давно (больше года назад) вырос из простого интерпретатора. На php делают более сложные задачи, чем "одинамичивание" домашних страниц. Он уже не медленный интерпретатор, как ты сказал. Скрипт компилируется и только после этого запускается ? рост производительности значительный. В дополнение к мощной системе php есть обработчики XML+XSLT, которые снимают с программиста, работающего над большим проектом, заботы о красивом оформлении страниц.
Если ещё остался интерес, отвечаю по пунктам:
1. Пускай верстальщики изучают XSLT ? не такой уж он сложный, да и сами они должны знать не только HTML, но и CSS, а так же немного JavaScript.
2. Разве валидность написания раньше не требовалась? Ну, да, я понимаю, что тег </table> многие писали только из уважения к былому величию компании Netscape. Но что поделаешь ? больше возможностей, нужно больше точности в работе, выше культура производства. Ведь если вы ездите, скажем, на "Тойоте-Марк-2", заправиться бензином на шоссе из ведра у пьянчуги будет плохой приметой, не так ли?
3. Не факт, что применение XML+XSLT замедляет отладку. Во-первых, в отличие от смеси HTML+PHP, на программисте не висит, например, вывод нумерованных списков, подсветка строк и множество прочей мелочёвки. По своему опыту могу сказать, что на эту мелочёвку тратится существенная доля времени. Кстати, XML+XSLT позволяет программисту и верстальщику отлаживать свои части проекта параллельно.
Во-вторых, анализатор синтаксиса в броузере будет молчать, как партизан, и просто ничего не выведет, если будет синтаксическая ошибка. А программа-валидатор умеет грамотно сообщать, что не так.
В-третьих, если XSLT лежит в файле, а XML формируется "на лету", то сделать возможность посмотреть XML-код несложно. Если новая версия сайта делается по адресу test.site.ru, можно сделать виртуальный хост xml-test.site.ru, и пусть php-скрипт смотрит, через какой виртуальный хост его вызывают. Если через "test", то вызывает обработчик XML+XSLT, если "xml-test", тогда выдаёт просто XML.
4. Настройка русского Саблотрона ? это, конечно, шаманство, но не настолько ужасная, как кажется.
5. Кто спорит, что это ресурсоёмко. Наименее ресурсоёмкая для сервера технология ? это Фронтпейдж и заливка готовых html-страниц на сервер. Скпритовые языки, модули Apache (например, mod_rewrite) ? это всё увеличивает ресурсоёмкость, но зато упрощает разработку.
6. Этот пункт вызывает особое удивление. Никто не предлагает заменять скриптовые языки на XSLT.
7. Ну, да, с там надо возиться отдельно (честно говоря, мне не приходилось, надо смотреть документацию). Но, по-моему, под "структурированными документами" ты имеешь в виду сложно структурированные.
8. Будут новые версии баз, будет и возможность работать с иерархическим документом. Пока что доступных технических средств достаточно, чтобы переводить данные из "линейных" таблиц в древовидные документы.
