Comments 29
> Проблема №1
Как преобразовывать структуры данных в дерево XML — зависит от выбранного языка разработки.
Рекомендуют все идентификационные данные объекта, закодированного в XML отображать в виде аттрибутов, а «контентную часть» — в виде узлов: User Name
> Проблема №2
В целом видение правильное. Ссылки на примеры? К примеру, начать отсюда: ru.wikipedia.org/wiki/XSLT
Появятся вопросы — отвечу в топике.
> Проблема №3
Для JS есть много разных библиотек-шаблонизаторов. Некоторые очень даже ничего. К сожалению, не могу найти ссылку, один даже пробегал на хабре.
А XSL1 в схеме не нужен — в место него должны быть те же $this->_data
Тогда XSL2 — это обычный XSL-шаблон для преобразований XML1
Как преобразовывать структуры данных в дерево XML — зависит от выбранного языка разработки.
Рекомендуют все идентификационные данные объекта, закодированного в XML отображать в виде аттрибутов, а «контентную часть» — в виде узлов: User Name
> Проблема №2
В целом видение правильное. Ссылки на примеры? К примеру, начать отсюда: ru.wikipedia.org/wiki/XSLT
Появятся вопросы — отвечу в топике.
> Проблема №3
Для JS есть много разных библиотек-шаблонизаторов. Некоторые очень даже ничего. К сожалению, не могу найти ссылку, один даже пробегал на хабре.
А XSL1 в схеме не нужен — в место него должны быть те же $this->_data
Тогда XSL2 — это обычный XSL-шаблон для преобразований XML1
Спасибо за ответ =)
> > Проблема №1
Язык — PHP. Рекомендации — понял. Только вот теперь появляется проблема с преобразованием данных из $this->_data в JSON. Скорее всего от формата JSON придётся отказаться. Буду думать…
> > Проблема №2
> Ссылки на примеры?
Ну да, на примеры. Но не по языку, а по организации XSL-шаблонов. Мне в основном нужен «образ и подобие», а дальше — я уж перейму
> > Проблема №3
Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(
> > Проблема №1
Язык — PHP. Рекомендации — понял. Только вот теперь появляется проблема с преобразованием данных из $this->_data в JSON. Скорее всего от формата JSON придётся отказаться. Буду думать…
> > Проблема №2
> Ссылки на примеры?
Ну да, на примеры. Но не по языку, а по организации XSL-шаблонов. Мне в основном нужен «образ и подобие», а дальше — я уж перейму
> > Проблема №3
Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(
что за проблема с преобразованием в json?
пример xml+xsl: d-o-b.ru/test/mud/
пример сериализатора хэшей: d-o-b.ru/?source:printer.page
пример xml+xsl: d-o-b.ru/test/mud/
пример сериализатора хэшей: d-o-b.ru/?source:printer.page
> Скорее всего от формата JSON придётся отказаться
Зачем отказываться? В чем трудность использовать JSON?
> Мне в основном нужен «образ и подобие», а дальше — я уж перейму
Я в свое время начинал учиться на примерах отсюда: www.w3schools.com/xsl/xsl_templates.asp
> Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(
Как-то на хабре пробегала ссылка на шаблонизатор с шаблонами в теле документа, которые были заключены в теги < script > с нестандартным type
Зачем отказываться? В чем трудность использовать JSON?
> Мне в основном нужен «образ и подобие», а дальше — я уж перейму
Я в свое время начинал учиться на примерах отсюда: www.w3schools.com/xsl/xsl_templates.asp
> Ну у меня и свой JS-шаблонизатор есть =) Только он скорее процедурный, чем декларативный. В этом то и загвоздка: непонятен принцип =(
Как-то на хабре пробегала ссылка на шаблонизатор с шаблонами в теле документа, которые были заключены в теги < script > с нестандартным type
А на какой платформе писать хотите? PHP? ASP.Net?
На PHP
Я сейчас работаю на проекте, где используется MVC на основе XSLT. Правда платформа — ASP.Net. Вещь довольно сложная, впрочем и интересная.
По сути вопросов:
1. В дотнете такое делается простой XML-сериализацией, как в РНР — я не в курсе.
2. Тут сложнее. У нас цепочка такая:
1) для каждой страницы есть метод, который возвращает XML вида
При чем сам метод возвращает только ноду method-response, а внешнюю оболочку дописывает отдельный хендлер.
2) Если мы сейчас тестируем проект, то тут все прекращается — такой XML достаточно для проверки корректности работы бизнес-логики.
3) Если же мы работаем не в тестовом режиме, то XML пережевывается XSL-преобразованием, которое для каждой страницы свое. Естественно, для уменьшения количества кода все оформленно в виде нескольких слоев макросов и шаблонов, что делает написание конечного преобразования довольно простым.
После третьего шага получаем готовую XML. Хендлер, упомянутый выше, обрабатывает GET и POST запросы от браузера, по ним определяет метод и параметры и посылает респонсы методов, прожеванные XSL-преобразованием.
3. Сложно сказать. У нас проект для интранета, потому AJAX почти не используется.
Как-то так =) Немного сумбурно вышло, но в двух словах такую систему сложно описать.
По сути вопросов:
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 почти не используется.
Как-то так =) Немного сумбурно вышло, но в двух словах такую систему сложно описать.
«После третьего шага получаем готовую XML.» следует читать как «После третьего шага получаем готовую HTML.»
До «внешней оболочки» я не додумался =) Надо будет тоже так сделать — скорее всего это будет полезно. Спасибо =)
Сейчас у меня есть только данные: 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
(там — полная абстракция =)
Сейчас у меня есть только данные: 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
(там — полная абстракция =)
1. идентификационные данные — тоже вполне себе контент.
2. удобно внутри системы гонять гламурные форматы — хэши и xml, а накладывать шаблон только при выводе нерадивому клиенту.
3. а вот тут при использовании xslt можно использовать одни и те же шаблоны как на клиенте, так и на сервере.
2. удобно внутри системы гонять гламурные форматы — хэши и xml, а накладывать шаблон только при выводе нерадивому клиенту.
3. а вот тут при использовании xslt можно использовать одни и те же шаблоны как на клиенте, так и на сервере.
У меня, видимо, не получится сначала собрать все данные «страницы», а уже потом — наложить XSL: я хочу, чтобы клиент обращался не к странице, а к Resource (что-то типа RESTful, только без HTTP-методов PUT и DELETE)
А, обращаясь к объекту, можно выбрать только данные объекта =) Дополнительные объекты для сборки страницы должны быть добавлены уже внутри шаблона.
А XSL на клиенте я использовать не могу: я его просто не знаю =(
А, обращаясь к объекту, можно выбрать только данные объекта =) Дополнительные объекты для сборки страницы должны быть добавлены уже внутри шаблона.
А XSL на клиенте я использовать не могу: я его просто не знаю =(
страница — композитный ресурс, который формирует свои данные посредством композиции данных из других ресурсов. например, ресурс «данные о пользователе» может запросить ресурс «топики пользователя», пересортировать полученные данные в нужном порядке, добавить инфу из ресурса «профиль пользователя» и «отдать дальше». когда юзер делает запрос — он попадает на специальный веб-фронт-контроллер, который парсит запрос во внутреннее представление и запрашивает нужный ресурс, а получив ответ накладывает на него нужный шаблон и отдаёт клиенту. при запросе через xml-rpc, шелл или что-нибудь другое — запрос придёт на другой фронт-контроллер, но запрос к «ресурсам» и их ответ будет точно такой же.
почему бы его не узнать? ;-)
почему бы его не узнать? ;-)
> страница — композитный ресурс
Так то он так. Но в моём варианте есть 2 контроллера, а в твоём — 3 (третий объединяет данные первых двух)
+ к тому, для введения спец.контроллера нужно 2 человека: программист-моделей-и-контроллеров и верстальщик, а без него — нужен только верстальщик =)
Так то он так. Но в моём варианте есть 2 контроллера, а в твоём — 3 (третий объединяет данные первых двух)
+ к тому, для введения спец.контроллера нужно 2 человека: программист-моделей-и-контроллеров и верстальщик, а без него — нужен только верстальщик =)
2 роли !== 2 человека
Мне хочется, чтобы было именно 2 человека. И я хочу заложить это в систему.
то, что ты пытаешься реализовать — приводит в конечном счёте к весьма печальным последствиям: верстальщик превращается в матёрого программиста, реализующего большую часть логики приложения на каком-нибудь убогом недоязыке (хслт, смарти и тп), а программист — в прокладку между верстальщиком и базой данных, выполняющую тупую работу по переводу «запроса ресурса» в «запрос sql» с последующим ещё более тупым переводом «таблицы значений» в «дерево хэшей или xml-дерево».
А мне всегда казалось, что это наоборот — хорошо. Программист должен быть прокладкой между БД и верстальщиком, Верстальщик — между программистом и манагером, а Манагер — между верстальщиком и клиентом (дизайнеры-враги-человечества как бы в стороне: они не прокладки =))
Так можно разделить зоны ответственности и достичь строго последовательного выполнения задачи, что в итоге приведёт к сокращению времени разработки.
Так можно разделить зоны ответственности и достичь строго последовательного выполнения задачи, что в итоге приведёт к сокращению времени разработки.
верстальщик — между программистом и браузером. а менеджер — между коммандой и заказчиком.
Это понятно, что всех «наших» можно обернуть словом «комманда», а менеджер и клиент — как бы в стороне. Но противоречий всё равно нет: последовательность действий команды должна идти строго к клиенту, по возможности не возвращаясь к предыдущим шагам.
Мой вариант последовательности мне кажется оптимальным.
Мой вариант последовательности мне кажется оптимальным.
любая разработка циклична. кроме вариантов «сдачи под ключ», когда ваше творчество придётся допиливать кому-то другому…
возможность быстро похачить приложение, вызвав два отдельных серверных метода и тем самым увеличив время обработки ровно вдвое — очень негативно сказывается в стратегическом плане.
менеджер невозмутимо транслирует странные и непонятные требования заказчика, «программист» спокойно пишет обёртки над бд с использованием ооп, паттернов и прочих достижений цивилизации. браузеры лениво брыкаются своими багами, стараясь выделиться на фоне остальных. а бедный верстальщик мечется как белка в колесе пытаясь их всех подружить используя только нож (шаблонизатор) да молоток (копипаста); переделывает по десять раз под уточнённые требования заказчика, очередные баги от тестера и новые сигнатуры методов от программиста.
возможность быстро похачить приложение, вызвав два отдельных серверных метода и тем самым увеличив время обработки ровно вдвое — очень негативно сказывается в стратегическом плане.
менеджер невозмутимо транслирует странные и непонятные требования заказчика, «программист» спокойно пишет обёртки над бд с использованием ооп, паттернов и прочих достижений цивилизации. браузеры лениво брыкаются своими багами, стараясь выделиться на фоне остальных. а бедный верстальщик мечется как белка в колесе пытаясь их всех подружить используя только нож (шаблонизатор) да молоток (копипаста); переделывает по десять раз под уточнённые требования заказчика, очередные баги от тестера и новые сигнатуры методов от программиста.
Ну я не спорю с тем, что разработка — циклична. Но мне цикличность не нравится и я хочу свести её к минимуму.
> возможность быстро похачить приложение
В каждом есть хотябы чуть-чуть дурака: например, программер может сделать тоже самое, что и верстак + к тому: команда — она на то и команда, чтобы иметь и пользоваться возможностью общаться друг с другом.
В любом случае — нет в мире совершенства.
> возможность быстро похачить приложение
В каждом есть хотябы чуть-чуть дурака: например, программер может сделать тоже самое, что и верстак + к тому: команда — она на то и команда, чтобы иметь и пользоваться возможностью общаться друг с другом.
В любом случае — нет в мире совершенства.
разница в том, что если похачит программист, то он потом сможет сделать нормально, ибо внешний интерфейс не изменится. а если верстальщик — то он капитально завяжется на этот хак и даже если программист сделает потом нужный метод — верстальщику придётся всё переделывать.
Если похачит верстальщик, то программист (опять же) потом сделает новый контроллер (если будет нужно). И переделывать не придётся, если в задаче будет чётко прописана структура данных.
Вобщем, если что-то сделано неправильно на «первых шагах» пути, то всё равно придётся переделывать все остальные шаги.
PS Мы друг друга не переспорим =) Ты говоришь, что некоторые ошибки — «почти фатальны», а я говорю, что большинство ошибок «легко исправимы». Я с тобой в принципе согласен, но считаю, что многое зависит от организации работы. Если у меня всё получится сделать — всё будет хорошо, если нет — ну чтож теперь поделаешь… =)
Вобщем, если что-то сделано неправильно на «первых шагах» пути, то всё равно придётся переделывать все остальные шаги.
PS Мы друг друга не переспорим =) Ты говоришь, что некоторые ошибки — «почти фатальны», а я говорю, что большинство ошибок «легко исправимы». Я с тобой в принципе согласен, но считаю, что многое зависит от организации работы. Если у меня всё получится сделать — всё будет хорошо, если нет — ну чтож теперь поделаешь… =)
> идентификационные данные — тоже вполне себе контент.
Это вопрос идеологии, а не четких определений.
кто-то пишет
text
а кто-то
123text
Это вопрос идеологии, а не четких определений.
кто-то пишет
text
а кто-то
123text
Sign up to leave a comment.
XSLT: Идеологические вопросы / проблемы