Сначало немного объясню суть.
В данный момент переписываю практически с нуля свою CMS систему. До этого использовал свой шаблонизатор - шаблоны были в HTML и проблем собственно не было. 
Почему задумался об XSLT... Хочется достичь того, чтобы практически весь вывод информации (включая всякие мелочи такие, как прописание дополнительных стилей в зависимости от получаемой информации и т.д.) можно было настроить в шаблонах. Наворачивать HTML-шаблонизатор всякими дополнительными функциями приведет к снижению скорости работы, и я вообще не вижу смысла изобретать псевдоязык, если есть такой сильный и мощный инструмент как XSLT.

Прикинув этапы прохождения информации:
1. Получение информации из БД MySQL. (Вся информация хранится именно там).
2. Составление XML файла с этой информацией.
3. Передача XML файла (или DOM-объекта) в шаблонизатор и указание какой XSL шаблон использовать. Соответственно обработка и вывод информации.

Но смущает одно:
Составление XML файла из информации полученной из БД MySQL - получается как бы дополнительный этап и есть подозрения, что скорость работы всей этой системы после такой организации шаблонов резко снизится.

Так вот хотел услышать мнения тех, кто уже писал что-то подобное. Или начинал писать, но остановился по каким-либо причинам. Как вы думаете, есть ли еще какие-либо минусы в данной структуре организации шаблонов?


P.S. Модераторы - оставьте пожалуйста тему в этом разделе форума. Заранее спасибо.

Ага... а использование XSLT ускорит? ;)


Есть native template уже. Зачем изобретать?

Этапы верные. Подозрения про скорость тоже. Но упадёт она не при генерации XML, а при применении XSLT-преобразования.

Опыт с XSL есть. Получается очень гибко, довольно сложно и не сильно быстро.

Это сообщение отредактировал(а) SamDark - 4.12.2007, 21:32

Как раз дописываю такую штуку. Насчет скорости честно говоря не заметил, но пока и страницы не особо сложные.
Минусов я пока особых не нашел, кроме того, что приходится разбираться в дополнение к php, xhtml, sql еще и с xml, xslt.
А так мне понравилось - отделение кода от дизайна почти стопроцентное. Почему почти - иногда надо вставить какую-то мелочь - типа заголовок, таблицу специального вида и т.п. Городить из-за этого очередной тег xml не хочется, вот и приходится все-таки вставлять чистый xhtml.


Это сообщение отредактировал(а) N0dwis - 5.12.2007, 01:25

Определитесь, какая у вас конечная цель - максимальная скорость или удобство редактирования шаблонов? И одним из этого пожертуйте ради второго, ведь как не крути, а максимальная скорость всегда будет вообще без использования шаблонизатора.

Один фактор не должен критически влиять на другой. Конечно же скорость может немного упасть, но не критически. Иначе смысла не будет во всей этой гибкости шаблонов.


Ну согласись, есть разница: использовать стандартное расширение PHP написанное на C или использовать для обработки дополнительных условий в шаблоне сам PHP.


Про изобретать - это я образно. Просто изучать язык шаблонов того же Smarty - это как синтаксис отдельного языка программирования, чем он лучше XSL сложно сказать.


Ну его можно прямо в XSL шаблон запихать и программный код не трогать...


Есть сомнения, но по фактам что-то против сказать не могу - возможно ты прав. 

Буду пробовать, если интересно буду отписываться в этой теме...

mishaSL, 

Посмотрите в сторону шаблонов в CakePHP. Там используется native-синтаксис. т.е. парсинга дополнительного нет. При этом всё довольно гибко.


Знаю. Поэтому и порекомендовал native-шаблоны.


И ещё один плюс к native-шаблонам.

Иногда не получается, да и удобнее просто вставить xhtml.


Что есть native-шаблоны в общем случае? CakePHP я ж понимаю платный, ну а сама технология что собой представляет? Где почитать?

N0dwis, 
CakePHP бесплатный 

native-шаблоны заключены в самом php т.к. php/fi изначально писался как шаблонизатор для си cgi.

Да все в этом замечательно. Но есть одно НО, хочется достичь четкого разделения данных, шаблонов и чтобы данные никак не были связаны с особенностями движка. Т.е. к примеру человек который абсолютно не знает что это за движок и его особенностей,  видит перед собой исходный XML файл, и соответственно одними только знаниями XSL настраивать весь вывод. Я думаю это должно быть очень удобно. 
Просто при использовнии native template в любом случае технология построения шаблонов начинает зависеть от движка.

Ладно, как-только допишу эту систему выложу здесь сравнительные тесты. Чтобы всем было понятно, насколько это все пригодно для использования, и на сколько уменьшается производительность по сравнению с теми же native-шаблонами. В любом случае считаю надо попробовать.

mishaSL, 
Это только при плохом использовании native template.

Попробовать можно. Но, в принципе, уже всё есть готовое ;)

Если есть ссылочка, поделись пожалуйста.

http://phptal.motion-twin.com/
http://www.xml.lt/Resources/Framework

SamDark, за ссылки большое спасибо, но

насколько я понял это еще один язык шаблонов... или я что-то не понял....


А это насколько я понимаю framework... может там и есть это, но пока что не разбирался подробно...

mishaSL, 

Это XSLT-шаблонизатор.

Шо-то это бред какой-то, а не шаблонизатор... Все равно все в куче - php, xhtml, xml.

N0dwis, 
mishaSL,
У меня начинает складываться впечатление, что вы хотите шаблонизатором отделить PHP от HTML, а не логику представления от логики работы приложения. Я всё правильно понимаю?

Ну да, я же это и писал.
При использовании xml логика представления вообще размазывается, смещается в xsl, а приложение только формирует нужные данные в нужном формате.
Кроме того, при таком подходе, изменить дизайн может даже человек не знакомый с программированием вообще и с php в частности.

N0dwis, 
Так вы про логику или про язык? Логика легко разделяется с использованием native-шаблонов.

К тому, же XSLT не так уж и легче PHP и человек, не знакомый с программированием вообще, XSLT, как по мне, не осилит.

Это сообщение отредактировал(а) SamDark - 6.12.2007, 16:05

Я про язык - не люблю дикую смесь php и html, которая есть практически во всех движках.
А xslt - осилит, проверено! Да и можно ж изменять существующие шаблоны, тогда еще проще...

N0dwis, 
Понятно. Вы хотите повторить Smarty на XSLT. Как сделаете - покажите, что выйдет. Интересно.

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

Это сообщение отредактировал(а) N0dwis - 6.12.2007, 16:53

N0dwis, 
Ну, можно сюда привести два кусочка кода:
1. Получение объекта и формирование XML.
2. Кусочек XSL, который всё это дело переводит в (X)HTML.

Конечно же нет.

SamDark, ты немного не понимаешь чего хочется достичь в итоге. Как допишу (на это уйдет примерно 5-6 недель) обязательно покажу и приведу сравнительную таблицу (плюсы и минусы) по отношению к другим методам шаблонизации на PHP.

Ок, буду ждать. Скорее всего данная тема интересна не только нам.

Ну да я тоже хочу посмотреть что в итоге получится!  Сам лично использую Smarty + Php !
Вот спрашивается зачем XML + XSLT если эффект от применения в итоге тот же XHTML  Не понимаю!
Ну выгрыш может и сыграет когда обработка XSLT будет на стороне клиента  Но тут есть свои разноогласия!
Попраьте меня если я не прав !  

Привожу куски кода (все классы находятся в разных файлах, привожу вместе только для примера):




После всех этих телодвижений получается где-то такое дерево xml. Это кусок из общего xml файла - преобразование выполняется сразу всей страницы, а не по частям.


А это кусок xsl, который выполняет преобразование


Ну а стили для всего вроде <div class="menu-item"> задаются отдельно в css файле, его приводить не буду, ничего особо интересного.

Так получается полное отделение html от php. Если прийдется даже самым кардинальным способом изменять дизайн - это затронет только xsl файл и класс для формирования этого куска xml, но чаще всего достаточно будет поменять только xsl. Кроме того, класс Menu, довольно специфичный, но я сделал еще несколько достаточно общих - таблица, список и т.п., и эти классы может применять уже не только один модуль, а многие для своих нужд.
Жду критику, замечания и идеи.   

Насчет преобразования на стороне клиента - думал, но там больше проблем - совместимость браузеров, проблемы с кнопкой "Назад", закладки. Ну а плюсы - код становится более понятным, проще изменение дизайна, возможность передавать данные сразу в xml - для мобильников например.

N0dwis, 
Хорошо вышло. Сейчас как раз работаю с такой вот системой на Java.

Совет:
Написать общий класс XMLDataElement, умеющий свои property преобразовывать в XML и от него отнаследовать все остальные классы для конктретных моделей данных. Заодно получится класс для генерации XML из не совсем стандартных данных.


p.s. преобразования на стороне клиента лучше не делать. Ещё рано. Браузерам от этого нехорошо...

Идея!!
Спасибо!! (жалко не могу еще поднимать репутацию)

Это сообщение отредактировал(а) N0dwis - 7.12.2007, 13:34

ващет "хорошие" броузеры сами говорят чего они могут а чего нет 
в HTTP заголовках 

Vaulter, 
К сожалению, не все хорошие и не все говорят правду.

SamDark, Дык. если он плохой, пусть жрет обычную HTML разметку (сделанную на сервере),
а если хороший (или врет что секёт в xml) кормим ему xml + xsl 
дабы снизить нагрузки на сервере.

Vaulter, 
Ну, когда нагрузка большая - это оправдано. А так - лишняя заморочка.

Это сообщение отредактировал(а) SamDark - 7.12.2007, 16:24

> Этапы верные. Подозрения про скорость тоже. Но упадёт она не при генерации XML, а при применении XSLT-преобразования.

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


> Жду критику, замечания и идеи.

вместо for-each лучше по возможности применять apply-templates. будет гибче.


> Насчет преобразования на стороне клиента - думал, но там больше проблем - совместимость браузеров, проблемы с кнопкой "Назад", закладки.

что там не так с кнопкой "назад" и закладками?? с аяксом не путаешь?


> p.s. преобразования на стороне клиента лучше не делать. Ещё рано. Браузерам от этого нехорошо... 

да ладно  не так уж всё и плохо 


> ващет "хорошие" броузеры сами говорят чего они могут а чего нет в HTTP заголовках

они не говорят, поддерживают ли они xslt 


формирование данных:


трансформация в xml:


вывод пользователю:


вот, что из этого в итоге получается 
 посредством этого шаблона 

ещё один пример

немного теории

Это сообщение отредактировал(а) egao - 9.12.2007, 14:15

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

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

Непонятно, почему логика приложения названа "дополнительным этапом".
Сам же пишет - "приложение только формирует нужные данные в нужном формате". Ну, если это лишний шаг - то я уже даже и не знаю. по мне - так это основная часть приложения. А вот шаблонизатор - это так, украшения. Сменить шаблонизатор для грамотно написанного скрипта - пара пустяков. 

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

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


Непонятно, если честно, чем "данная структура" отличается от любых других. Вроде бы, система везде одна и та же - получили нужные данные и отдали их шаблонизатору. Или я его-то не понял?

Feldmarschall, 
Читаем внимательней. Хотелось разделить php и вёрстку, а не логику и представление.

Про структуру вы правы: все шаблонизаторы одинаковы.

Я читал. На второй странице. Но несмотря на употребляемые им термины, автор, все-таки, разделяет именно логику приложения и логику представления. 

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

Зато нашёл гораздо более серьёзный недостаток:



Ежу понятно, что это перечеркивает всю идею и все заявления о том, что "Если придется даже самым кардинальным способом изменять дизайн - это затронет только xsl файл".
Особенно учитывая, что все наши проекты состоят из таких "мелочей".

Feldmarschall, 

Ох. Ну я же говорю, что "несмотря на термины, которые он употребляет".
Вообще, мы о чем сейчас говорим? О том, что я неправильно цитирую букву высказываний автора? О том, что я невнимательный?
Или, все-таки, о сути его действий? Я предпочитаю последнее.

В отделении "пхп от хтмл" как таковом нет смысла.
Делать что-то имеет смысл, если у тебя есть объективные причины.
Я могу назвать 3-4 объективные причины отделять логику представления от логики отображения.
Разделять же "пхп и хтмл" ни одной объективной причины назвать нельзя.
А как он там это называет - дело десятое. 

Заявления типа "мне не нравится дикая смесь" и "я написал движок, который позволяет легко сменить дизайн" (как будто движок с native шаблонизатором этого не позволяет!) - исключительно субъективные. И обсуждать их тогда вообще бессмысленно. Все равно что спорить, что вкуснее - яблоки или колбаса. 

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

Тем более, что сам автор, в результате, так до конца их и не разделил.

Это сообщение отредактировал(а) Feldmarschall - 12.12.2007, 13:49

Feldmarschall, 
Смысла для меня лично нет, но не для автора. У автора причины субъективны. Но они тоже причины. Он спросил, как сделать, чтобы ему было вкусно, а не как сделать универсально и правильно.

p.s. я-то пытался в самом начале навести на правильный путь, но не вышло...

Я назвал ее выше, может не в явной форме. Причина - возможность довольно кардинально поменять дизайн сайта человеку, абсолютно не знакомому с php и смутно представляющего себе что такое программирование вообще.
Плюс еще одна причина - такой движок довольно легко можно переделать для wap (пока близко не сталкивался, но там же вроде идет чистый xml).
Кроме того, native шаблоны даже программисту будет править довольно тяжело - опять смесь php и html тяжело воспринимается.


Ну во-первых никто не идеален. Во-вторых это относится к очень уж экзотическим мелочам, если элемент встречается больше 2-х раз, уже есть смысл для него создать отдельный класс представления и стандартизировать его. Да и сейчас я использую вставку xhtml чаще всего просто для сообщений пользователю типа "Неправильный пароль". Ну а в третьих - я над этим работаю.



Назовите объективные причины.



Правильно вообще понятие относительное, но от хорошей идеи никогда не отказывался. Буду благодарен за объяснение.

N0dwis, 


В контроллере соотв.:



Шаблон:


Это сообщение отредактировал(а) SamDark - 12.12.2007, 17:56

N0dwis, спасибо за интересный ответ.
Прежде, чем отвечать по пунктам, хочу задать один вопрос:
Скажи, почему ты так сопротивляешься определению "отделение логики приложения от логики представления"? Что тебе кажется в нем неправильным? Неприложимым к твоему случаю?


Это сообщение отредактировал(а) Feldmarschall - 12.12.2007, 19:14

Я не сопротивляюсь, а полностью поддерживаю! Просто я задавался целью именно отделить код html от кода php, т.к. смотреть на вот это

немного утомительно (кусок из php-fusion).
А отделение логики приложения от логики представления - классическая в общем-то задача, решается с помощью MVC-подобных паттернов (Mediator, Observer), хотя честно признаюсь на php я это не реализовывал, только на С++  . 
Если использовать еще и шаблоны в смысле отделения php от html, то класс View делится еще на 2 - собственно логика представления и внешний вид представления (где-то так, хотя теорию я по этому поводу не развивал  ).
SamDark, спасибо!

P.S. Вспомнил еще один плюс связки xml+xslt - не разрываются теги html. Обычно в шаблонизаторах код шаблонов храниться в нескольких файлах (даже если в одном - проблема остается) и получается, грубо, что теги, скажем, <body> и </body>, будут находиться в разных файлах, либо в разных частях файла - опять нарушается логика и восприятие. В случае же xslt - каждый блок представляет собой законченный кусок с начальным и конечным тегом.

Возьмем два куска кода.
Один из примера, SamDark,  второй - из примера на w3schools.com


положа руку на сердце, сможешь ли ты сказать, что первый чем-то принципиально отличается от второго?

Если речь только про "смотреть на это", то к чему все эти рассказы про объективные причины и возможность кардинанльно поменять дизайн сайта?
Все, что ты говоришь объективного, относится к разделению логики приложения и логики отображения. И относится, в том числе, к native PHP шаблонам. Получается, ты приписываешь своему разделению чужие свойства. 

Вот и остается из твоих "объективных" причин только "утомительно смотреть".
Давай и с этим разберемся
Перепишем приведенный тобой пример по-человечкски:


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

Принципиально, ничем, я уже говорил. Для программиста вообще идентичные. Но с точки зрения дизайнера, мне кажется, первый легче для восприятия. Я не прав?

Чем легче-то?
Кто такой, вообще, этот "дизайнер"? Человек с Фотошопом и Иллюстратором? Он HTML в глаза не видал.
Как ни спроси любого пхпшника, для чего ему шаблон - он отвечает, "шобы дизайнер мог править!". А спрашиваешь, кто режет шаблоны у них в конторе - "программииииисты...". В лучшем лучае - верстальщик.
Интересно, почему на Яндексе годами висят объявления "нанимаем верстальщиков XSLT"? почему там не написано "Дизайнеров XSLT"?
В результате столько сил угрохивается ради... мифической фигуры! 

С точки зрения дизайнера, говоришь?
Проведи простой эксперимент.
Возьми реальный, я подчеркиваю - реальный шаблон на XSLT. Не учебный пример типа того, что я приводил выше, а боевой шаблон. В котором проверок и условий побольше будет, чем приведенном тобой куске из fusion. И покажи знакомому дизайнеру. Смутно представляющему себе что такое программирование вообще.
А потом поговорим.

Перепишу завтра. Сегодня уже голова не варит. Но общую идею понял. Ты хочешь сказать, что на xml это все будет выглядеть еще запутанней. Что ж, может быть, не спорю. Но попробуй все-таки подсунуть этот кусок кода, который всем программистам кажется простым и понятным, дизайнеру... Пошлет я думаю далеко...
Кстати, вопрос по существу, а где в такой схеме место теме сайта (ну в смысле оформлению)? Что она должна делать, если вся верстка уже сделана, причем довольно жестко?

Добавлено через 1 минуту и 43 секунды
Все время опаздываю с ответом на один пост...   

N0dwis, 
Приведённый вами лопшекод такой не из-за того, что используется php.



На эту тему есть у нас замечательный two-step-view.

Нет, не хочу. Я не хочу сказать, что XSLT хуже, чем PHP
Я хочу сказать, что PHP не хуже XSLT.

Я хочу сказать, что  шаблон в принципе представляет собой программу. На каком бы языке она ни писалась, она все равно останется программой. И рассуждать за бедного дизайнера не имеет смысла.  Если надо исправить только оформление - любой, знакомый с HTML и CSS исправит в нужных местах любой шаблон. Если надо будет исправлять логику вывода - без знаний программирования не обойдешься.

И что я хотел сказать с самого начала: что ты, на самом деле, занимался, все-таки, отделением программы, получающей данные, от программы, данные выводящей. Называя это "отделением PHP от HTML". Хотя разницы, на каком языке программирования написан шаблон, нету.

У связки XML+XSLT есть свои плюсы. но ты их практически ни одного не озвучил, приводя вместо них те доводы, которые прекрасно относятся и к нелюбимому тобой PHP. вот ради восстановления справедливости я и влез в этот топик =)


Не очень понял вопрос. по мне, "тема сайта" - это такой же шаблон, как и другие.
Что значит "верстка уже сделана"? Есть хтмл файл с мордой сайта? Делаем что и обычно - режем из этой морды шаблон. Вставляя в него программные конструкции.


Чума! Мы думаем совершенно одинаково, практически одними и теми же словами! =)))

????


Почему нелюбимой? Просто пытаюсь прогресс двигать!   
Честно говоря со своей колокольни больше не вижу... Ajax?


Нет, я не это имел в виду. "верстка уже сделана" относилось к текущей генерации страницы, что вывод html осуществляется самим классом View, а не темой. Сейчас объясню. Если использовать модульную архитектуру cms, а не монолит, то класс (модуль, блок) View - это часть логического модуля сайта (ну там, новости, форум и т.п.). А тема уже будет определять, как это все выглядит, задавать ОБЩИЙ стиль. Я вижу 2 варианта - либо писать тему для каждого модуля (т.е. шаблон), но при этом нужно переписывать абсолютно все шаблоны для всех модулей... А если в системе есть те модули, для которых эта тема не прописана? Либо выносить в тему некое общее оформление, типа обрамления какого-нибудь блока, но тогда не получиться полностью поменять дизайн, т.к. даже при смене темы многие куски будут жестко заданы в самих модулях.
Т.е. приходим к тому, с чего начали - те же самые проблемы, что и у меня со вставкой в xml кусков html. Собственно этого я и хотел добиться, когда разрабатывал на xml - чтобы сам движок генерировал только данные, а полностью весь html настраивался бы. Есть ли другое решение? Может я путанно объяснил конечно...


Родственники наверное... Индийское кино какое-то...  

Это сообщение отредактировал(а) N0dwis - 12.12.2007, 22:13

N0dwis, 
http://ooad.asf.ru/Pattern.aspx?IdKat=7&IdPat=18

Реализовано много раз. Мной в том числе.


Хм... в модулях(контроллерах, если точнее) не должно быть ничего, что имеет отношение к представлению данных. Всё это для View. Тогда такой проблемы не будет.

В любом случае см. two-step-view.

Ну и чем two-step-view отличается от того, что делаю я??
То же самое, просто я в качестве "логического экрана" использую xml!!!!

Цитата:

То же, что я указывал как недостаток, что приходится вставлять html напрямую!!!!

Блин, надо было раньше эту статейку почитать, сразу бы многие грабли отпали...

Это сообщение отредактировал(а) N0dwis - 12.12.2007, 22:37

Именно.


Ну да. Тут либо единое оформление, либо не единое. View можно построить так, что использование общего View (его, кстати, часто зовут layout-ом) опционально.

p.s. сорри, что не дал статью раньше.

Спасибо все равно. Есть еще что-то похожее?  

N0dwis, 
Похожее на что?

Ну паттерны именно для Web-программирования...

N0dwis, 
Есть.

http://www.phppatterns.com/docs/start

Класс! Спасибо, то, что нужно!