XSLT: Идеологические вопросы / проблемы

[IntenT]

> Проблема №1
Как преобразовывать структуры данных в дерево XML — зависит от выбранного языка разработки.
Рекомендуют все идентификационные данные объекта, закодированного в XML отображать в виде аттрибутов, а «контентную часть» — в виде узлов: User Name

> Проблема №2
В целом видение правильное. Ссылки на примеры? К примеру, начать отсюда: ru.wikipedia.org/wiki/XSLT
Появятся вопросы — отвечу в топике.

> Проблема №3
Для JS есть много разных библиотек-шаблонизаторов. Некоторые очень даже ничего. К сожалению, не могу найти ссылку, один даже пробегал на хабре.
А XSL1 в схеме не нужен — в место него должны быть те же $this->_data
Тогда XSL2 — это обычный XSL-шаблон для преобразований XML1

[Covex]

Спасибо за ответ =)

> > Проблема №1
Язык — PHP. Рекомендации — понял. Только вот теперь появляется проблема с преобразованием данных из $this->_data в JSON. Скорее всего от формата JSON придётся отказаться. Буду думать…

> > Проблема №2
> Ссылки на примеры?
Ну да, на примеры. Но не по языку, а по организации XSL-шаблонов. Мне в основном нужен «образ и подобие», а дальше — я уж перейму

> > Проблема №3
Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(

[tenshi]

что за проблема с преобразованием в json?

пример xml+xsl: d-o-b.ru/test/mud/
пример сериализатора хэшей: d-o-b.ru/?source:printer.page

[Covex]

С самим преобразованием — никаких проблем: Zend_Json::encode($data) и всё.
Но есть «Проблема №3» — не хватает алгоритма.

А в код сериализатора я, пожалуй, подсмотрю =)

[IntenT]

> Скорее всего от формата JSON придётся отказаться
Зачем отказываться? В чем трудность использовать JSON?

> Мне в основном нужен «образ и подобие», а дальше — я уж перейму
Я в свое время начинал учиться на примерах отсюда: www.w3schools.com/xsl/xsl_templates.asp

> Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(
Как-то на хабре пробегала ссылка на шаблонизатор с шаблонами в теле документа, которые были заключены в теги < script > с нестандартным type

[tenshi]

javascript.ru/unsorted/templating

[Covex]

> В чем трудность использовать JSON?
Трудность — в проблеме №3 =) Если отказаться от её решения, то от схемы на картинке придётся так же отказатся и подгружать аяксом не «данные+шаблон», а «text/html» (а это мне не нравится — не красиво как-то)

[mace]

А на какой платформе писать хотите? PHP? ASP.Net?

[Covex]

На PHP

[mace]

Я сейчас работаю на проекте, где используется MVC на основе XSLT. Правда платформа — ASP.Net. Вещь довольно сложная, впрочем и интересная.
По сути вопросов:
1. В дотнете такое делается простой XML-сериализацией, как в РНР — я не в курсе.
2. Тут сложнее. У нас цепочка такая:
1) для каждой страницы есть метод, который возвращает XML вида

<root>
<method_response name="home">
  <string>home</string> 
  <object1 att1="asdf">
    <object2 att2="cvvzc"/>
  </object1>
  <object3 att3="dasfsdaf"/>
</method_response>
<invoke-params>
  <param name="redirectURL" is-null="yes" /> 
  <param name="redirectURLLeft" is-null="yes" /> 
</invoke-params>
<session windows-account="true">
  <user login="test" FullName="test" /> 
<roles>
  <role name="authenticated" /> 
  <role name="administrator" /> 
</roles>
</session>
</root>

При чем сам метод возвращает только ноду method-response, а внешнюю оболочку дописывает отдельный хендлер.
2) Если мы сейчас тестируем проект, то тут все прекращается — такой XML достаточно для проверки корректности работы бизнес-логики.
3) Если же мы работаем не в тестовом режиме, то XML пережевывается XSL-преобразованием, которое для каждой страницы свое. Естественно, для уменьшения количества кода все оформленно в виде нескольких слоев макросов и шаблонов, что делает написание конечного преобразования довольно простым.
После третьего шага получаем готовую XML. Хендлер, упомянутый выше, обрабатывает GET и POST запросы от браузера, по ним определяет метод и параметры и посылает респонсы методов, прожеванные XSL-преобразованием.
3. Сложно сказать. У нас проект для интранета, потому AJAX почти не используется.

Как-то так =) Немного сумбурно вышло, но в двух словах такую систему сложно описать.

[mace]

«После третьего шага получаем готовую XML.» следует читать как «После третьего шага получаем готовую HTML.»

[Covex]

До «внешней оболочки» я не додумался =) Надо будет тоже так сделать — скорее всего это будет полезно. Спасибо =)

Сейчас у меня есть только данные: restful.joos.nnov.ru/a0/data/index.xml (а это HTML: restful.joos.nnov.ru/a0/data/index.html)
А потом всё это должно быть вставлено в конечную HTML-страницу: restful.joos.nnov.ru/a0/index.html
(там — полная абстракция =)

[tenshi]

1. идентификационные данные — тоже вполне себе контент.
2. удобно внутри системы гонять гламурные форматы — хэши и xml, а накладывать шаблон только при выводе нерадивому клиенту.
3. а вот тут при использовании xslt можно использовать одни и те же шаблоны как на клиенте, так и на сервере.

[Covex]

У меня, видимо, не получится сначала собрать все данные «страницы», а уже потом — наложить XSL: я хочу, чтобы клиент обращался не к странице, а к Resource (что-то типа RESTful, только без HTTP-методов PUT и DELETE)
А, обращаясь к объекту, можно выбрать только данные объекта =) Дополнительные объекты для сборки страницы должны быть добавлены уже внутри шаблона.

А XSL на клиенте я использовать не могу: я его просто не знаю =(

[tenshi]

страница — композитный ресурс, который формирует свои данные посредством композиции данных из других ресурсов. например, ресурс «данные о пользователе» может запросить ресурс «топики пользователя», пересортировать полученные данные в нужном порядке, добавить инфу из ресурса «профиль пользователя» и «отдать дальше». когда юзер делает запрос — он попадает на специальный веб-фронт-контроллер, который парсит запрос во внутреннее представление и запрашивает нужный ресурс, а получив ответ накладывает на него нужный шаблон и отдаёт клиенту. при запросе через xml-rpc, шелл или что-нибудь другое — запрос придёт на другой фронт-контроллер, но запрос к «ресурсам» и их ответ будет точно такой же.

почему бы его не узнать? ;-)

[Covex]

> страница — композитный ресурс
Так то он так. Но в моём варианте есть 2 контроллера, а в твоём — 3 (третий объединяет данные первых двух)

+ к тому, для введения спец.контроллера нужно 2 человека: программист-моделей-и-контроллеров и верстальщик, а без него — нужен только верстальщик =)

[tenshi]

2 роли !== 2 человека

[Covex]

Мне хочется, чтобы было именно 2 человека. И я хочу заложить это в систему.

[tenshi]

то, что ты пытаешься реализовать — приводит в конечном счёте к весьма печальным последствиям: верстальщик превращается в матёрого программиста, реализующего большую часть логики приложения на каком-нибудь убогом недоязыке (хслт, смарти и тп), а программист — в прокладку между верстальщиком и базой данных, выполняющую тупую работу по переводу «запроса ресурса» в «запрос sql» с последующим ещё более тупым переводом «таблицы значений» в «дерево хэшей или xml-дерево».

[Covex]

А мне всегда казалось, что это наоборот — хорошо. Программист должен быть прокладкой между БД и верстальщиком, Верстальщик — между программистом и манагером, а Манагер — между верстальщиком и клиентом (дизайнеры-враги-человечества как бы в стороне: они не прокладки =))

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

[tenshi]

верстальщик — между программистом и браузером. а менеджер — между коммандой и заказчиком.

[Covex]

Это понятно, что всех «наших» можно обернуть словом «комманда», а менеджер и клиент — как бы в стороне. Но противоречий всё равно нет: последовательность действий команды должна идти строго к клиенту, по возможности не возвращаясь к предыдущим шагам.
Мой вариант последовательности мне кажется оптимальным.

[tenshi]

любая разработка циклична. кроме вариантов «сдачи под ключ», когда ваше творчество придётся допиливать кому-то другому…

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

менеджер невозмутимо транслирует странные и непонятные требования заказчика, «программист» спокойно пишет обёртки над бд с использованием ооп, паттернов и прочих достижений цивилизации. браузеры лениво брыкаются своими багами, стараясь выделиться на фоне остальных. а бедный верстальщик мечется как белка в колесе пытаясь их всех подружить используя только нож (шаблонизатор) да молоток (копипаста); переделывает по десять раз под уточнённые требования заказчика, очередные баги от тестера и новые сигнатуры методов от программиста.

[Covex]

Ну я не спорю с тем, что разработка — циклична. Но мне цикличность не нравится и я хочу свести её к минимуму.

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

В любом случае — нет в мире совершенства.

[tenshi]

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

[Covex]

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

Вобщем, если что-то сделано неправильно на «первых шагах» пути, то всё равно придётся переделывать все остальные шаги.

PS Мы друг друга не переспорим =) Ты говоришь, что некоторые ошибки — «почти фатальны», а я говорю, что большинство ошибок «легко исправимы». Я с тобой в принципе согласен, но считаю, что многое зависит от организации работы. Если у меня всё получится сделать — всё будет хорошо, если нет — ну чтож теперь поделаешь… =)

[tenshi]

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

[IntenT]

> идентификационные данные — тоже вполне себе контент.
Это вопрос идеологии, а не четких определений.
кто-то пишет
text
а кто-то
123text

[tenshi]

что сказать-то хотел? =)

код лучше сюда не постить — вебдваноль с ним не очень дружит — воспользуйся каким-нибудь пастебином…