Это все понятно. И, честно говоря, из этой статьи я так и не понял, чем XML Sapiens лучше XSLT. Простая "автоматизация дизайна" выполняется с помощью XSLT, более сложные вещи лучше перекладывать на сервер. Зачем здесь изобретать еще один велосипед, который лишь повторяет уже имеющиеся инструменты? Причем делает это, как мне на первый взгляд показалось, несколько запутанно.
Я полностью согласен с вами: "Схема XML + XSLT мой процесс устраивает больше как минимум из-за большей простоты понимания".
А на счет клиентской стороны... Opera не поддерживает XML+XSLT (или последние версии уже поддерживают?), что значительно ограничивает область применения такого подхода.
Описание функциональности сайта с помощью XSLT - весьма трудоемкая задача. Кроме того, XSL-шаблон слишком зависим от XML-документа с данными, что ограничивает гибкость решений на основе данной технологии.
А разве XSLT предназначен для этого? Это же лишь таблицы стилей. Вся функциональность должна быть вынесена в программный код, а XSLT - это ведь не язык программирования. Иначе опять получается смешение функциональности и визуального представления, от чего мы так пытаемся избавиться.
Если подобный конструктор формирует тарифный план только в первоначальный момент, при покупке хостинга, а потом пользователь не сможет ничего поменять, то такая схема, конечно, не слишком вразумительна. В данном случае каждый покупатель ставится в неудобное положение - ведь прямо здесь и сейчас надо предусмотреть, какая функциональность тебе может понадобиться (пусть и не сразу), а какая так никогда и не пригодится.
Гораздо более привлекательнее, на мой взгляд, выглядит схема, когда я, независимо от того, какие услуги выбрал при покупке хостинга, могу в любой момент изменить свой тарифный план. Например, сегодня мне не нужна какая-то функциональность - я за нее и не плачу. Завтра она мне понадобится - я просто подключу новую услугу и буду платить немного больше. Потом, когда она мне снова не будет нужна - выключу ее обратно.
Преимущество в том, что при покупке хостинга клиенту (который в данный момент может и не представлять, что ему нужно) не надо думать о том, что может понадобиться для его сайта через год. Такие примеры уже есть, и я бы не назвал их неудачными.
Я полностью согласен с вами: "Схема XML + XSLT мой процесс устраивает больше как минимум из-за большей простоты понимания".
А на счет клиентской стороны... Opera не поддерживает XML+XSLT (или последние версии уже поддерживают?), что значительно ограничивает область применения такого подхода.
А разве XSLT предназначен для этого? Это же лишь таблицы стилей. Вся функциональность должна быть вынесена в программный код, а XSLT - это ведь не язык программирования. Иначе опять получается смешение функциональности и визуального представления, от чего мы так пытаемся избавиться.
Гораздо более привлекательнее, на мой взгляд, выглядит схема, когда я, независимо от того, какие услуги выбрал при покупке хостинга, могу в любой момент изменить свой тарифный план. Например, сегодня мне не нужна какая-то функциональность - я за нее и не плачу. Завтра она мне понадобится - я просто подключу новую услугу и буду платить немного больше. Потом, когда она мне снова не будет нужна - выключу ее обратно.
Преимущество в том, что при покупке хостинга клиенту (который в данный момент может и не представлять, что ему нужно) не надо думать о том, что может понадобиться для его сайта через год. Такие примеры уже есть, и я бы не назвал их неудачными.