parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Ответ

Misha v.3 08.11.2005 18:20

приведенный кусок xsl-я решает задачу преобраззовать один xml в другой. т.е. это совершенно не показательный пример. может там один деятель написал такой изначальный xml что для того чтобы с ним потом можно было нормально работать потребовалась дополнительная трансформация.
1. Иллюзия простоты XSLT шаблонов.
Проекты на XML+XSLT очень тяжело поддерживать клиентам. Специалистов по XSLT очень мало, технологичный шаблон может подправить только специалист очень высокой квалификации. Таким образом, развеялась иллюзия, о простоте для клиентов и удобстве в управлении.
дата написания этого текста - 2003 год. сейчас их уже больше, и их количество растет в силу того что это достаточно удобный для своих задач инструмент. что касается поддержки клиентом - так это решается другими средствами: wysiwyg редакторами, которые выдают xml, который в свою очередь хранится в БД :)
2. Иллюзия управляемости и гибкости.
Шаблонов XSLT в большинстве своем недостаточно для написания серьезной бизнес логики в публичной части сайта. XSLT не дорос до полноценного языка программирования.
звиняйте, но тут вам никто не предлагал переносить логику работы в xsl. если логику оставить парсеру (в нашем случае), то xml получается маленький. (да, он все равно будет сильно проигрывать по скорости прямой генерации html-я).
4. Иллюзия удобства абстрагирования данных и внешнего вида.
Один из плюсов, за которым все гонятся, используя технологии XML+XSLT - добиться качественно абстракции внешнего вида. Но только уже после создания первых шаблонов все понимают, что абстракция получилась, только никому она уже больше не нужна. Шаблон XSLT очень сложен для представления внешнего вида.
см. ответ V12. это особенность конкретной реализации шаблонов. к слову скажу что тот xml что выдает imp1 для основных элементов сайта остается одинаковым (с незначительными изменениями) почти с самого начала.
Полная смена дизайна требует полного переписывания всех шаблонов
ну... а в других системах не надо ничего переделывать? :)
тут-же нужно переделывать только шаблоны (если не меняется логика)ю

ну и если дочитать до конца, то:
...
Значит ли это, что надо вообще отказаться от XML? Конечно нет.
...
Можно ли добиться абстрагирования продукта от дизайна и бизнес-логики? Конечно, возможно.
...
Можно ли увеличить производительность и сохранить динамический контент? Конечно можно.
...
основная мысль:
xml - достаточно удобный, текстовый формат для хранения и обмена данными. не вижу смысла использовать много разных форматов, если они не дают значительных преимуществ.

да, кстати... если уж важна скорость, то написать regexp который разберет одноуровневый xml - не сложнее чем написать оный для разбора ini файликов.