[Hubbitus]

А вы знаете, y13 высказал очень простую, но вместе с тем (как всегда) грамотную вешь: Дизайнер должен заниматься дизайном, зачем ему вообще учить что-либо, может действительно ему достаточно разработать концепцию, пример, скажем на чистом HTML и с тестовыми данными (кстати я так и получаю почти всевремя), а "прикрутить" дизайн это уже работа программера, и как он это сделает и что удобно использовать должно быть для него (и для других программеров, если есть в проекте)!!!???

Да и RaZEr прав, что касается все-таки сложности реализации...

denver:
Насчет противоречий двух фраз - не вижу никаких противоречий. Если верстальщик понимает XSLT то XSLT его не шугает А то что учить XSL придется я посчитал как раз за минус.

Мы какраз исходим из того что Дизайнер ничего кроме HTML какбы и не знает, и пытаемся решить стоит ли ему учить XSLT (или что-то другое из обсуждаемого здесь), или может вполне достаточно десятка абсолютно простых и стандарных PHP-конструкций!

denver:
Насчет скорости XSLT -- надо тестировать, я не зря говорил о гипотетичной быстроте процессора XSLT, т.к. процессор процессору рознь. Есть слухи что в PHP5 он намного быстрее чем sablotron из PHP4. И дальше скорее всего он тоже будет оптимизироваться. Но не исключено что и в PHP4 скорость парсинга PHP->XML->XSLT->HTML быстрее чем парсинга Smarty->PHP->HTML, только по тому что шаг XML->XSLT->HTML делается одной функцией: echo xslt_process($xml, $xsl). Мне вот подсознательно кажется что одна функция лучше чем много других Уравняем шансы договорившись что результирующий HTML будет одинаковый, соответсвенно сложность Smarty кода будет примерно равна сложности XSLT. Однако это очевидо что код Smarty-"процессора" написан на PHP, а код XSLT-процессора на языке более (если не самого) низкого уровня. Надеюсь я понятно аргументировал.

Да, нужно тестировать, согласен, однако позволю себе не согласится почти со всем сказанным в цитате выше:
Про парсинг XML в разных версиях PHP и про разные парсеры я не могу особенно говорить - нету опыта. А вот "Но не исключено что и в PHP4 скорость парсинга PHP->XML->XSLT->HTML быстрее чем парсинга Smarty->PHP->HTML, только по тому что шаг XML->XSLT->HTML делается одной функцией: echo xslt_process($xml, $xsl)." более чем странное заявление - Во-первых, не мне Вам как программисту говорить что одна функция это совсем не показатель скорости, и сама она может работать крайне медоенно, и от реализации зависит, и вызывать она может (да и вызывает, я почти уверен) сотни других, и Во-вторых, например Smarty парсит свой шаблон один раз, переводит его в PHP и все, выполняется дальше этот кешь, при последующих запросах, тоесть ВООБЩЕ исключается задержка на нем, шаблон перекомпилируется снова только после изменения исходного...

denver:
Просто вы не говорили еще о следующем и я не стал указывать. Но таки в проблеме "шаблониовании" подразумевается какой-либо один из двух подходов (или двух проблем):

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

denver:
Другой вопрос -- что тебе важнее разделять. Быть может с этого и надо было начинать? Иногда (а в идеальном, портируемом коде -- всегда) лучше не засорять PHP переменными содержащими цвета элементов и все такое остальное (субъективное). Вот в таком случае без знаний некого третьего языка -- языка управления отображением не обойтись, будь то Smarty или XSLT.

С этого и надо возможно начинать, только опять же, решить бы это в общем случае. Да, я согласен что лучше не засорять подобными вещами ПХП, но значит (если требуется), нужно просто предусмотреть так чтобы дизайнер мог эти параметры задать в шаблоне, не прибегая опять же к программированию, тоесть например не задвать специально переменные $color для четных и нечетных рядов, а сделать разделение этих рядов, чтобы дизайнер мог прописать цвета. Согласен, не всегда это делается легко и очевидно в любом выбранном подходе...

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

	<posts>
		<post>
			<user>denver</user>
			<message>bla-bla-bla</message>
		</post>
		<post>
			<user>RaZEr</user>
			<message>RTFM</message>
		</post>
	</posts>

А дизайнер опять же должен определить в шаблоне цикл по постам.... И это вместо того чтобы просто передать массив $posts в шаблонизатор, который также обработает шаблон с циклом по постам!!!

denver:
Из "актуальных проблем эксплорера" достаточно смирится только с тем что <script> должен иметь закрывающий элемент именно в виде </script>

Нееет, далеко не в этом только, в приведенном топике по моей ссылке вы могли прочитать достаточно обоснованной ругани по этому поводу, плюс http://www.hixie.ch/advocacy/xhtml да и еще много другого, стоит только поискать чуть-чуть...