Эта тема на forum.dklab.ru


Друже Бобер: Архитектурные принципы и реализация XML/XSLT CMS и шаблонизаторов
Приветствую!
Создать данную тему меня побудило осознание факта того, что я не понимаю сабж, и по-моему, плохую освещённость этого вопроса в сети именно на архитектурном уровне.

Собственно, каковы же основные архитектурные принципы построения сабжа?

Как я смог понять, прочитав то огромное количество различных постов форумов, статей, вкратце описывающих базовые принципы в очень абстрактной манере и прочих околофлеймовых, сводящихся к холливару, высказываний народа, основную суть сабжа, я могу выразить буквально в нескольких предложениях, а именно:
Основной принцип XML/XSLT систем управления контентом сводится к тому, что уровень Логики Домена (Domain Model, Model, бизнес-логика и т.д.), выполнив, собственно заложенную в неё функциональность, в качестве результата своей работы возвращает часть данных в формате валидного XML, который, затем парсит XSLT-шаблонизатор, формируя конечный (X)HTML.

В общем, для уяснения основных архитектурныхпринципов, вроди как-бы достаточно, однако, сразу же возникает масса других вопросов, решать которые необходимо уже на более низком, конкретном уровне, вот, некоторые из наиболее насущных для меня сабжевых вопросов:

1. принцип, по которому Домен будет отдавать XML
допустим есть есть некая таблица БД users, после выполнения запроса и возврата данных уровнем Доступа к Данным уровню Логики Домена, мы будем иметь некий массив - результат выборки из таблицы. Далее, Домен же, должен создать из этого массива строку, являющуюся XML-выражением, ну и возвратить в контроллер (ну или что мы там используем)... так вот
1.1. Как мы создаём эту XML-строку, что будет являться именами элементов, аттрибутов и т.д.? Допустим, мы ВСЕГДА (то есть, как стандарт де-факто) во всём движке извелкаем данные исключительно ассоциативно, и тогда именами елементов части XML документа, будут являться имена атрибутов таблицы, которая учавствовала в запросе. Однако, здесь ИМХО существует один очень краеугольный подводный камень, который я обозначу во втором вопросе

2. Куда (в какой объект, часть парадигмы MVC и т.д.) мы передаём сформированную XML-строку(DOM-документ)
То есть, например, мы решили хранить все результаты ответов, работы скриптом и т.д. в неком объекте Response, выполненном например в виде композитного Реестра, Тулкита (Service Locator) и т.д., тогда, как именно мы должны будем строить "дерево" ответа в процессе передачи Доменом на уровень выше (в контроллер) и затем собственно в сам Response.
Ну и конечно же, как будет осуществляться парсинг этого XML-документа,- то есть, что бы применить XSLT к XML-документу полученному таким способом (имена елементов = имена столбцов БД) верстальщик должен знать структуру БД (ну не столько как DML, а скорее DDL) - имена столбцов и т.д. что есть ещё большим злом, чем любая логика, кроме логики форматирования, в представлении (например, шаблоны Smarty, которые самостоятельно лезут в БД, что бы создать циклическую навигацию по сайту - меню переходов по страницам с их номерами и т.д.)

Здесь, мне не понятен уже сам принцип кооперации верстальщика и программиста, способ которым руководствуется верстальщик, создавая конкретные XSLT правила для конкретного варианта использования (результата действия комманды) и т.д.

В общем, существует ещё очень много непонятных мне здесь вещей, однако, надеюсь, что полное освещение этих двух вопросов, помогут мне самостоятельно представить остальную часть архитектуры в движках этого типа.

Спасибо.

зы: любые, расцениваемые вами линки по сабжу, очччень приветствуются!!!
reactorx:
Задался я подобной целью года два назад... или полтора -)
написал...

Что я с этого получил: опыть использовать xslt в работе, узнал что такое sedna, понял где лучше применять xml.

В общем выскажу ниже сугубо личное мнение и не иначе...
Хотя и кажется что использовать xslt как шаблонизатор это круто... стоит отогнать от себя эти мысли... это нифига не круто -)
Это реальный геморой и куча постоянно возникающего головняка.

Относительно базы это вы прально заметили... именно так я и реализовал... пхп выгребает данные формирует xml и колбеком возвращается вся эта фигня в шаблон...

Вопрос в другом... для чего это все нужно? все эти танцы с бубном и обертки на обертки...

Я для себя вывел формулу... не использовать сторонних шаблонизаторов... акромя PHP конечно -))) коим он и является...
Использовать готовые фреймворки или создовать небольшие под конкретный проект.

П.С по сабжу, скажу следущее... каждую технологию лучше всего применять в том месте для которого она разрабатывалась...

использовать xslt при парсинге скаченых html страниц действительно круто -))) и удобно... регекспы с ни не сравнятся в этом...
Конвертить один xml (html) в другой... то же шикарно...

П.П.С а вообще все советую разобраться с xslt очень полезно для кармы -)
Друже Бобер:
Спасибо, что откликнулись!

Собственно, постараюсь не начинать сразу же отходить от сабжевой темы, в темы околофлеймовые типа что-то vs что-то ещё, отвечу просто по-сути:

зачем мне это нужно:
...ради конечных клиентов, некоторые из старых заказчиков ни о чём и слушать не желают, кроме как XML CMS
ну и для себя разумеется, ибо видите тенденция какая пошла: XSLT - это круто
хотя, лично мне кажется, что XSLT-шаблонизаторы весьма удобны, это стандарт и прочее. В общем, комментировать эти мои ответы пожалуйста не надо, так как тема рискует остаться нераскрытой ;)
Исаак Тынгылчав:
Я вообще-то не программиcт. Поэтому в своих собственных проектах парадигмы не придумываю, а тупо в модели формирую XML, а во View делаю XSLT.
Как вариант часть XML (XSLT) может подсасываться через include в XSLT, это позволяет кэшировать часть запросов и делать XSLT-преобразования менее нагруженными.
Для бэкофисов View вообще можно заменить клиентским преобразованием. Сейчас все броузеры нормально с этим справляются. Хотя свои проблемы там тоже есть.

В двух больших проектах которых работал схемв была следующая.
Каждый метод контроллера описывался набором вызываемых сервисов и XSL-преобразований. Глубина преобразований могла быть сколь угодно большой, но реально 2-3 шага.
На предпоследнем шаге выдавалась простая страница прототипа. Это позволяло абстрагироваться от дизайна и быстро двигаться при создании новых методов. На последнем шаге - добавлялся дизайн и всякие приблуды - реклама, анонсы новостей и т.п.

>Здесь, мне не понятен уже сам принцип кооперации верстальщика и программиста, способ которым руководствуется верстальщик
Он намного проще чем в стандартных шаблонных движках, где функции программиста и верстальщика путаются.
При составлении ТЗ описывается XML-схема данных которые должен передавать верстальщику программст.
Для удобства каждая страница проекта может при передаче определенного GET-параметра устроить стриптиз и показать XML.
См. например:
http://erum.ru/article/18
http://erum.ru/article/18~xml Далее исходя из схемы и дизайна верстальщик лепит XSLT. Т.ч. программисту и верстальщику вообще не очем особо разговаривать.
reactorx:
2Исаак Тынгылчав да в вашем случае использование данной технологии (XSLT) уместно и я бы даже сказал круто получилось -)!
Исаак Тынгылчав:
2Исаак Тынгылчав да в вашем случае использование данной технологии (XSLT) уместно
мой случай - клинический :)
Клиентский XSLT если когда-нибудь будет актуален, то не ранее чем через 5-7 лет. Хотя к тому времени м.б. придумают что-то покруче.
reactorx:
клинический случай был мой -)
совмещение разметки и логики в нутри xslt, того что не хватало дергали колбеком из пхп -)
понятное дело тупизм, но все же это были просто эксперименты и процесс изучения xslt

а по поводу xslt как шаблонизатор в принципе дело обстоит очень хорошо... да же ваш пример показывает на сколько... а трансформацию можно и на сервере проводить...
по поводу нагрузки ... хм... ну можно же и кэширование привинтить -)

И еще момент... если наступит тот день о котором вы говорите (5-7 лет)... это будет не реально круто -) синдикация и тп прелисти web 2.0 будут реальны в глобальном масштабе... представьте обращается какойнить ресурс к другому ресурсу и получает готовый xml... который можно как отдать пользователю, так и переработать для внутренних нужд... хы и поисковикам будет проще... ненада парсить html... хотя это уже другая история...
Короче говоря открывается куча перспектив если это дело пойдет...
Но на данный момент... пока технологии застряли на уровне 80 - 90х годов (не буду развивать эту тему, кто не согласен смотрите даты создания стандартов на w3c и тот же rfc по tcp/ip -))) я для себя решил не использовать сторонние шаблонизаторы... а юзоть пхп как шаблонизатор и к нему фреймворк либо опенсорс какойнить либо писаный под конкретный прожект (писал об этом выше).
П.С но все же в сторону xslt тянет и очень сильно -))))

П.П.С сори за то что тему увел в офтоп -) не бейте ногами -)

Эта тема на forum.dklab.ru