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


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