-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Концепции шаблонов: 2 подхода
- Автор темы Yurik
- Дата начала
![[DAN]](/talk/data/avatars/m/0/23.jpg?1320946380){kind=avatar}
Мне бы было все же интересно услышать что-то конкретное и в примерах о сравнении xml+xslt с .php-based шаблонными движками.
Сам с темой xslt знаком весьма поверхностно (на уровне чтения манов
), ибо
1) xslt стоит не везде
2) не знаю, как обстоят дела в php, но "скорость" работы ms xml parser впечатляет :/
Сам с темой xslt знаком весьма поверхностно (на уровне чтения манов
), ибо1) xslt стоит не везде
2) не знаю, как обстоят дела в php, но "скорость" работы ms xml parser впечатляет :/
redbaron
Guest
сорри, это вовсе не технология xml-xslt.
Это движок.
Ссылку дать не могу, в сети нет и не будет в скором времени, просто не горю желанием.
"Пиши" означает "если интересно пиши на емайл".
Макс
Старожил PHPClub
с HTML_Template_IT я не работал, не знаю, а вот в Sigma ИМХО проще плагины вызывать через callback-функции.
Пример шаблона:
Код:
<table>
<tr><td> [b] func_plugin('vote')[/b] </td></tr>
<tr><td> [b] func_plugin('top10', 10)[/b] </td></tr>
</table>
PHP:
$tpl->setCallbackFunction('plugin', 'load_plugin');
function load_plugin($plugin_name) {
...// функция будет подгружать нужный плагин,
... // обрабатывать входные параметры и возвращать HTML
}nRay
Guest
Очень интересная тема.
Вопрос идеологический. Как по вашему, определять набор "плагинов" на странице должен программист или дизайнер, а точнее програмная логика или логика представления? Что гибче и проще в дальнейшей поддержке?
php, как видно, генерит xml по запросу, а xslt получает ноду, которой небыло в исходном документе, но понадобилась. Очевиден минус такого подхода: таскать данные с собственного хоста черех http. С другой стороны, определив названия модулей и набора параметров к ним дизайнер(верстальщик) получает всё необходимое для построения страницы любой сложности независимо от программера. Логика представления в коде отсутствует напрочь. Да и реализация моделей в данном случае прозрачна и очевидна, никаких прожект-специфик уловок и прочего неочевидного кода. Модель(обект модели) просто отдаёт "плоские" данные незаботясь не о их представлении не о зависимости их от других моделей.
Кстати, есть лучшее решение (запрос данных не по http)?
ПС: Мне искренне непонятна "инертность" всех слоёв девелопментской братии относительно xml. Возможно я не понимаю каких-то принципиальных подводных камней либо что-то ещё. Но уже на втором месте работы никак не могу убедить коллег не "сверху" ни "снизу" относительно удобства и необходимости использования этой технологии. Уважаемые, гуру, просвещайте, плз.
Вопрос идеологический. Как по вашему, определять набор "плагинов" на странице должен программист или дизайнер, а точнее програмная логика или логика представления? Что гибче и проще в дальнейшей поддержке?
Когда разрабатывал проект с использованием XML+XSLT не нашел ничего лучшего, чем функцию xslt - document('http://localhost/get_module_data.php?module=top_links&count=5')
php, как видно, генерит xml по запросу, а xslt получает ноду, которой небыло в исходном документе, но понадобилась. Очевиден минус такого подхода: таскать данные с собственного хоста черех http. С другой стороны, определив названия модулей и набора параметров к ним дизайнер(верстальщик) получает всё необходимое для построения страницы любой сложности независимо от программера. Логика представления в коде отсутствует напрочь. Да и реализация моделей в данном случае прозрачна и очевидна, никаких прожект-специфик уловок и прочего неочевидного кода. Модель(обект модели) просто отдаёт "плоские" данные незаботясь не о их представлении не о зависимости их от других моделей.
Кстати, есть лучшее решение (запрос данных не по http)?
ПС: Мне искренне непонятна "инертность" всех слоёв девелопментской братии относительно xml. Возможно я не понимаю каких-то принципиальных подводных камней либо что-то ещё. Но уже на втором месте работы никак не могу убедить коллег не "сверху" ни "снизу" относительно удобства и необходимости использования этой технологии. Уважаемые, гуру, просвещайте, плз.
fisher
накатила суть
обсуждение выбора движка шаблонов/whatever не имеет смысла без разговора о команде и предметной области.
дабы придать словам немного конкретики - два примера.
/* под логикой понимаем итераторы, условный переход, передача/заведение параметров внутрь по иерархии вызовов и тд */
две организации - выпускают, хостят-поддерживают крупнейшие электронные сми. первый вариант - проекты сильно отличаются друг от друга, много разной логики при показе страниц - логика в движке есть. что тут яйца, а что курица - не совсем однозначно. в результате выясняется, что для адекватного ведения проектов конторе надо три-четыре верстака, причем складывается, что им неплохо бы разбираться в программировании. вертальщик с навыками программирования иногда хочет сделать не просто, а "красиво", по-программерски, и все бы ничего, но иногда в шаблонах верстальщика сам автор ни хрена понять не может, не говоря уж обо всех остальных.
второй вариант - логики нет никакой вообще, даже сопливого ифа. с другой стороны, в большинстве проектов и бизнес-правила и модели данных более-менее стандартизированы, причем порой политической волей - большая часть проектов именно "подгоняется" под некую обобщенную модель. верстальщик - один + немного мата от девелоперов, логику реализующих, пишуших условия и циклы в презентационной части (но заметим делающих это разумеется и качетсвеннее и быстрее непрограммистов). ситуации, когда "там так наворочено, что не разобраться" практически не возникает.
в обоих случаях девелоперов - примерно одинаковое количество/качество.
спешу обратить особое внимание, что это лишь частные примеры, причем несмотря на некий эмоциональный окрас, обе модели в-общем удовлетворительны. на 99% уверен: при реализации проектов со сложной бизнес-логикой и пользовательскими интерфейсами выгоднее (очень осторожно) двигаться в сторону второго варианта - с логикой в движке, но минимальной. передача параметров + несколько вариантов операций условного перехода, имхо этого более чем достаточно.
да, есть пример ещё одного движка. там программер практически вообще практически ничего не делает, только базу проекторивует. остальное "продвинутая верстка". вот это имхо полный ад для веб-производства.
дабы придать словам немного конкретики - два примера.
/* под логикой понимаем итераторы, условный переход, передача/заведение параметров внутрь по иерархии вызовов и тд */
две организации - выпускают, хостят-поддерживают крупнейшие электронные сми. первый вариант - проекты сильно отличаются друг от друга, много разной логики при показе страниц - логика в движке есть. что тут яйца, а что курица - не совсем однозначно. в результате выясняется, что для адекватного ведения проектов конторе надо три-четыре верстака, причем складывается, что им неплохо бы разбираться в программировании. вертальщик с навыками программирования иногда хочет сделать не просто, а "красиво", по-программерски, и все бы ничего, но иногда в шаблонах верстальщика сам автор ни хрена понять не может, не говоря уж обо всех остальных.
второй вариант - логики нет никакой вообще, даже сопливого ифа. с другой стороны, в большинстве проектов и бизнес-правила и модели данных более-менее стандартизированы, причем порой политической волей - большая часть проектов именно "подгоняется" под некую обобщенную модель. верстальщик - один + немного мата от девелоперов, логику реализующих, пишуших условия и циклы в презентационной части (но заметим делающих это разумеется и качетсвеннее и быстрее непрограммистов). ситуации, когда "там так наворочено, что не разобраться" практически не возникает.
в обоих случаях девелоперов - примерно одинаковое количество/качество.
спешу обратить особое внимание, что это лишь частные примеры, причем несмотря на некий эмоциональный окрас, обе модели в-общем удовлетворительны. на 99% уверен: при реализации проектов со сложной бизнес-логикой и пользовательскими интерфейсами выгоднее (очень осторожно) двигаться в сторону второго варианта - с логикой в движке, но минимальной. передача параметров + несколько вариантов операций условного перехода, имхо этого более чем достаточно.
да, есть пример ещё одного движка. там программер практически вообще практически ничего не делает, только базу проекторивует. остальное "продвинутая верстка". вот это имхо полный ад для веб-производства.
Crazy
Developer
nRay, лично я не испытываю проблем по той простой причине, что не рассматриваю XSLT как технологи построения шаблонных движков -- просто как один из возможных вариантов построения последнего слоя (визуализатора).
Соответственно, нет никаких проблем ПЕРЕД визуализацией вставить в дерево любые дополнительные данные. Соответственно, шаблон описывается не на XSL, а не собственном расширении. Аналогично нет проблем с тем, чтобы поставить второй каскад ПОСЛЕ XSLT.
"Инертность" объясняется тем, что куча странных книжек и статей продвигают XSLT как законченное и готовое к немедлеенному использованию решение, каковым оно не является. Соответственно, многие пробуют и уходят.
Соответственно, нет никаких проблем ПЕРЕД визуализацией вставить в дерево любые дополнительные данные. Соответственно, шаблон описывается не на XSL, а не собственном расширении. Аналогично нет проблем с тем, чтобы поставить второй каскад ПОСЛЕ XSLT.
"Инертность" объясняется тем, что куча странных книжек и статей продвигают XSLT как законченное и готовое к немедлеенному использованию решение, каковым оно не является. Соответственно, многие пробуют и уходят.
nRay
Guest
Crazy
Таким образом, ты хочешь сказать, что страница сайта описывается сначала "внутренним шаблоном"/конфин-фалом/что-то ещё/(нужное подчеркнуть), далее на основе этой информации программа "грузит" необходимые модули, получает результирующие данные и отдаёт их "визуализатору"?
Если я не правильно понял, то прошу пояснить подробнее. В противном случае вопросы:
1 Кто и как определяет "шаблоны собственного расширения"?
2 Где же тут разделение логики от представления? похоже что эту самую границу локализовали в определённой степени, но кто от этого выиграл пока непонятно.
3 Выгоды (плюсы) такого подхода?
Таким образом, ты хочешь сказать, что страница сайта описывается сначала "внутренним шаблоном"/конфин-фалом/что-то ещё/(нужное подчеркнуть), далее на основе этой информации программа "грузит" необходимые модули, получает результирующие данные и отдаёт их "визуализатору"?
Если я не правильно понял, то прошу пояснить подробнее. В противном случае вопросы:
1 Кто и как определяет "шаблоны собственного расширения"?
2 Где же тут разделение логики от представления? похоже что эту самую границу локализовали в определённой степени, но кто от этого выиграл пока непонятно.
3 Выгоды (плюсы) такого подхода?
nRay
Guest
Crazy, если позволишь, ещё вопрос.
Соклько раз происходит парсинг xslt-файла? Ты умеешь за один заход определить какие модули нужны, активировать их, получить данные и наложить на эти данные шаблон?
Соклько раз происходит парсинг xslt-файла? Ты умеешь за один заход определить какие модули нужны, активировать их, получить данные и наложить на эти данные шаблон?
nRay
Guest
Автор оригинала: Crazy
Меня интересует вот это:
Каким образом это реализуется? Очевидно, что, xml и xsl одновременно поступают на обработку парсеру-визуализатору. А вопрос вобщемо-то уже звучал, как динамически, на основании правил xslt-шаблона получить данные от моделей, если сам список моделей определяется только на этапе разбора xslt, т.е. подразумевается, что xml к этому времени, так же должен быть "готов"?
Меня интересует вот это:
XSLT у тебя, как я понял, определяет и какие именно данные(от каких модулей) нужны и как их отобразить.
Каким образом это реализуется? Очевидно, что, xml и xsl одновременно поступают на обработку парсеру-визуализатору. А вопрос вобщемо-то уже звучал, как динамически, на основании правил xslt-шаблона получить данные от моделей, если сам список моделей определяется только на этапе разбора xslt, т.е. подразумевается, что xml к этому времени, так же должен быть "готов"?
nRay
Guest
Похоже, разговор грозит коснутся оригинальных авторских решений решений, что понятно.
В любом случая спасибо, Crazy, на интересные мысли диалог натолкнул.
Думаю следующая моя реализация будет приблизительно следующая:
XSLT - файл(либо завязанная на название пара файлов), таки будет описывать и какие данные получать и как их представлять. Таким образом при первом проходе файла определяем дополнительные модули, которые сформируют дополнительный xml, а при втором просто наложим xslt шаблон. Естественно, речь идёт только о "дополнительных модулях", т.е. наличие и необходимость которых определяет не контроллер, а желание верстальщика.
В любом случая спасибо, Crazy, на интересные мысли диалог натолкнул.
Думаю следующая моя реализация будет приблизительно следующая:
XSLT - файл(либо завязанная на название пара файлов), таки будет описывать и какие данные получать и как их представлять. Таким образом при первом проходе файла определяем дополнительные модули, которые сформируют дополнительный xml, а при втором просто наложим xslt шаблон. Естественно, речь идёт только о "дополнительных модулях", т.е. наличие и необходимость которых определяет не контроллер, а желание верстальщика.