Использование Шаблонов технологии, принцип и все ЗА и ПРОТИВ

[shuron]

Сообщение от Hubbitus

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

какраз таки из его постов подчерпнул много интересного!
лови харизму

Сообщение от dacuan

Подведем итог.
Предложенные технологии:
1) Синтаксис ПХП.
- плюсы - быстрый не требуется переучиваться, большая функциональность и поддержка всех возможностей ПХП;
- минусы - нечеткое разделение кода и дизайна, слабая переносимость шаблонов (при реализации проекта на другом языке, шаблоны придется переделать).
2) Стандартные шаблонизаторы (Smarty, FastTemplate)
- плюсы - более сильное разделение дизайна и кода;
- минусы - не так быстры, как синтаксис ПХП, при переносе проекта необходимо будет кроме основного кода переносить и шаблонный движок.
3) XML/XSLT
- плюсы - полное разделение дизайна и кода, хорошая переносимость (работа с XML/XSLT реализована в большинстве современных языков);
- минусы - неясен вопрос производительности (по крайней мере для меня), вводится промежуточный способ хранения данных (XML).

Если у кого что есть добавить, прошу высказываться, только без постов вида "... рулит, все остальное %#@$"

Может вернёмся сюда и обсудим ещё павру пимеров за и против..
я пока тендирую к пункту 2) но писать свой...

[denver]

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

PHP вставки:
Недостаткии у вставок PHP кода типа <?=$var?> я вижу такие:
1. Это дыра, т.к. дизайнер или еще кто-то кто не отвечает за PHP код имеет полный доступ ко всем переменным сайта, может неакуратно проверить работает ли exec("rm -rf *.*") и т.д.
2. Ээээ... да и нет больше недостатков в принципе. Вот только что по-идиотски выглядят шаблоны сайта. Верстальщика и правда может шугать, потому-что человека шугает все что он не понимает, такова природа.
А верстальщики понимающие PHP долго не живут (ну переквалифицируются в программеров).

Темплейты:
Темплейты типа FastTemplate, Smarty и пр. решают в принципе первую проблему. Но вторую просто вуалируют, при этом создавая каждый свой новый миниязык, который хоть и несложно понять, но непонятно зачем.
Но...
Не все темплейты одинаково полезны, некоторые добавляют еще и проблем верстальщикам, т.к. иногда миниязык темплейтов отнюдь не является валидный кодом или частично использует преимущества html, как например использует <!-- комментарии HTML --> для своих целей:

<!-- BEGIN list -->
<table>
   <!-- BEGIN list_item -->
     <tr>
       <td>
         {item_title}
       </td>
     </tr>
   <!-- END list_item -->
</table>
<!-- END list -->

Комментарии не предназначены для этого! оставьте право (или возможность) использовать комментарии верстальщику! Довольно сложно например после таких вставок закоментировать весь этот приведенный блок, т.к. комментарии HTML не могут быть вложенными друг в друга. Кроме того комменты эти (по сути не комменты, а инструкции, отсутствие которых может привести к фатальной ошибке) могут быть запросто проигнорированы в визуальных редакторах HTML.

XML/XSL:
Вот тут не прозвучало ничего верного. Некоторые считают что XML должен заменить базу данных под MySQL, а кое-кто предлагает записывать данные в БД и в XML параллельно (кой нафиг толк в БД тогда? ). Но абстрагируйтесь от XML как от формата хранения. Система темплейтов основанная на XML использует (должна использовать) этот самый XML только для отображения, причем промежуточного, данных (не совсем корректно сказать следующее -- но все же для передачи нужных данных в XSL). Как это работает (вернее как должно работать):
Вся задача PHP сводится к тому чтобы создать переменную содержащую например следующий текст:

<page>
	<title>Imho.ws / Варезник / Агнитум аутпост 2.0</title>
	<user>denver</user>
	<thread>
		<page>1</page>
		<lastpage>25</lastpage>
		<post>
			<user>User1</user>
			<message>Hello everybody, need crack</message>
		</post>
		<post>
			<user>denver</user>
			<message>RTFM</message>
		</post>
		<post>
			<user>User1</user>
			<message>Hello everybody, need crack</message>
		</post>
	</thread>
</page>

Причем данная переменная содержит только тот текст (не считая тэгов, хотя они тоже важны) который будет в конце концов в конечном HTML. Не обязательно выводить все посты если будет показана лишь страница номер 1. Необязательно выводить все треды если будет показан только тред "Агнитум Аутпост 2.0" и т.п. Не нужно мегабайтных XML файлов. XML создается налету, а данные берутся из БД.
Итак, у нас есть уже XML (в памяти), применяем к нему файл showthread.xsl и отдаем получившийся HTML пользователю.

Возникает вопрос зачем генерировать XML (чтобы потом его еще и XSLем обрабатывать) если можно сразу в HTML пропарсить? А затем что у вас в ПХП станет на десяток меньше str_replace'ов (не надо парсить никаких переменных), на пару-тройку меньше preg_match'ей (нет смысла извлекать из темплейтов блоки <!-- BEGIN block1 --> ... <!-- END block1 --> чтобы их продублировать нужное количество раз). Это задача процессора XSLT. И (гипотетически) модуль XSLT будет конвертировать XML в HTML быстрее чем ваш PHP код со всеми str_replace'ами и preg_match'ами вместе взятыми. А кроме того:

Плюсы такого подхода:
1. Никакой зависимости от оформления. Т.к.:

а) неважно в каком месте XML (в начале или в конце) находится какая-то переменная или блок, XSLT выведет (или не выведет) его в том месте HTML в котором надо.
б) Больше никаких "двойных" блоков (или лишней переменной $bgcolor например) если надо сделать таблицу с зеброй. Зебру будет делать XSLT.
в) XSLT даже может создать навигацию страниц типа: Страница 2 из 25 (на первую) [1], [2]...[25] (на последнюю). Единственно что нужно это задать в XML что-то типа <thread page="2" lastpage="25"> ну или как угодно, главное чтобы валидно.
д) Верстальщик может менять XSL а программер XML одновременно, не боясь получить логических ошибок типа "нужный блок не найден" и т.п.
е) а также е) ж) з)... -- PHP код сводится к минимуму, т.к. все (буквально все) задачи связанные с отображением и дизайном переключаются на XSLT ("вставьте мне сюда серое, а тут белое, через одно" - вали к верстальшику, в коде PHP этого быть не должно. "Хочу чтобы каждая первая буква параграфов была картиночкой с прикольной буквочкой" - к верстальщику, "Здесь тоже мининавигацию вставить" - туда же). Задача PHP -- вывести только необходимые _реальные_ данные.


2. Скорость вывода XML + обработка его XSL (не забываем что это практически встроенная функция) теоретически больше чем парсинга переменных и блоков в HTML (не забываем о куче str_replace, preg_match).

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

4. Никаких дырок и пр.

Минусы:
1. (первый и последний). Верстальщику придется знать XSLT (хоть и не шибко сложный, но энивэй) (хотя с другой стороны - если не XSL, так Smarty, который не понятно что за язык и непонятно с каким будущим).
2. (ан нет, не последний). HTML должен соответствовать XHTML, т.е.больше никаких незакрытых тэгов, никаких инвалидных закрытй типа <b><i></b></i> и т.п. Но это даже полезно будет.

ЗЫ. Кроме того. Не сегодня так завтра, когда все больше браузеров смогут обрабатывать XML + XSL сами (сегодня это только мозилла последних версий и IE начиная с 6.0) весь парсинг можно вообще перекинуть на сторону клиента -- отадавать сгенерированный XML (включаем в него также ссылку на XSL). Но это все будет только лет через 5, когда старые браузеры наконец исчезнут (блин, когда ж они все исчезнут).

[Hubbitus]

denver, КРУТО, описано все четко и подробно.

Поэтому так и хочется задать множество вопросов, как профессионалу:
1) В PHP-вставках вида <?=$var?> единственное что ты нашел из недостатков это возможная кривость рук дизайнера и "по-идиотски выглядят шаблоны сайта". Первое может присутствовать в любом подходе и даже допуская именно в этом большую опасность, не хочу брать это в расчет. Второе - конечно ты прав, да и с шаблонными движками наблюдается похожее, НО, согласись, XSL, каким бы не был "встроенным", должен обрабатывать XML парсить его и превращать во что-то другое, соответственно полюбому будет медленнее чем ничего не делать а просто выводить, как в этом случае
Да и заявления из разных частей поста:

denver:
Верстальщика и правда может шугать, потому-что человека шугает все что мы он понимает, такова природа.

denver:
Верстальщику придется знать XSLT (хоть и не шибко сложный, но энивэй)

помоему слегка противоречат друг-другу, ведь если чего-то учить, то когда с нуля поидее всеравно что...

denver:
Возникает вопрос зачем генерировать XML (чтобы потом его еще и XSLем обрабатывать) если можно сразу в HTML пропарсить? А затем что у вас в ПХП станет на десяток меньше str_replace'ов (не надо парсить никаких переменных), на пару-тройку меньше preg_match'ей (нет смысла извлекать из темплейтов блоки <!-- BEGIN block1 --> ... <!-- END block1 --> чтобы их продублировать нужное количество раз).

Гениально просто конечно, а валидный XML на PHP не теми же str_replace'ами и preg_replace'ами создать придется? Да, наверное его проще сгенерировать на PHP и быстрее, но нужно не забывать что после этого еще и обработка должны быть, так что быстрее это спорно...

И еще, возможно главный вопрос, вот ты говоришь про всякие рюшечки

denver:
PHP код сводится к минимуму, т.к. все (буквально все) задачи связанные с отображением и дизайном переключаются на XSLT ("вставьте мне сюда серое, а тут белое, через одно" - вали к верстальшику, в коде PHP этого быть не должно. "Хочу чтобы каждая первая буква параграфов была картиночкой с прикольной буквочкой" - к верстальщику, "Здесь тоже мининавигацию вставить" - туда же).

- это ли уже будет в итоге не программированеи вывода, только верстальщиком???? Ты уверен что это правильная расстановка приоритетов? Помоему в идеале (повторю в идеале, поскольку куча сложностей с этим возникает на практике), дизайнер-верстальщик какраз должен только оформлением заниматься, тоесть не считать количество страниц (из твоего примера) в заданном в XML диаппозоне, не считать сколько страниц пропустить, заменив на "...", а (в идеале) просто задать скажем, что страницы должны отображаться красным шрифтом, 14 кегля, а текущая - зеленым, 16 и все, остальное поумолчанию, если он не задал... Опять же очень актуальные проблемы с парсингом xhtml в Експлорере. Да и большой, очень огромный размер документов/шаблонов на XML тоже весьма не последний фактор помоему...

[y13]

С Hubbitus, по поводу приоритетов абсолютно согласен. А вот с предыдущими 2 страницами, совершенно не согласен.
Если брать под ваши требования, тогда скажу так: Вот под perl, есть ведь такой модуль HTML::Template, который хоть и имеет свой псевдоязык, но лихо решает многие проблемы связанные с шаблонизацией. В нём решена проблема с комментариями, путём внедрения в код "песвдо-тегов" (тем кому эта проблема не мешает, можно продолжать пользоваться комментариями).

А если с точки зрения управления процессом производства: Я вообще что-то не совсем понимаю, с чего этот топик начался. Есть чёткое разделение труда, отделяющее дизайн от программирования. Не с того конца смотрите, думаю что шаблонизация, это проблема программиста в первую очередь: дизайнер ему выдаёт готовый к работе шаблон, а программист уже в свою очередь уже разбирается, как и зачем его продукт этот шаблон использует. Программисту намного проще разобраться в html коде, чем дизайнеру учить псевдоязык.
Насколько я знаю, GUI пишется в последнюю очередь (в нормальных проектах), а вы тут пытаетесь телегу впереди лошади поставить. Написали систему? Давайте дизайнеру спецификацию требуемого шаблона. Получили шаблон - прикрутили к системе. Все довольны.

Или я не прав?

[RaZEr]

Вы не забывайте, что XML будет посложнее в реализации. То хостер консерватор-придурок не ставит нужные расширения, то любимая программка не понимает UTF-8, то клиент хочет сам редактировать HTML, при этом икая услышав "W3C Recommendation" или "Valid XHTML".

[denver]

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

а валидный XML на PHP не теми же str_replace'ами и preg_replace'ами создать придется?

Валидный XML не так уж и сложно производить: берем $var и записываем как "<".$foo.">".htmlspecialchars($var)."</".$foo.">". Единственное несложное правило
str_replace не нужен. т.к. никакого шаблона самого XML не существует. В каждом php файле (ну т.е. для каждого типа страниц) будет свой, таким каким захочет его сделать программер (будем считать что программер тут имеет выбор), в идеале -- таким который отвечал бы логике страницы -- (представь например идеальную страницу топика без любого форматирования и выведи ее). В конце концов выводишь ты не для человека, еще раз напомню -- это промежуточный вывод.

Насчет скорости 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-процессора на языке более (если не самого) низкого уровня. Надеюсь я понятно аргументировал.

это ли уже будет в итоге не программированеи вывода, только верстальщиком????

Тут ты верно подметил. Просто вы не говорили еще о следующем и я не стал указывать. Но таки в проблеме "шаблониовании" подразумевается какой-либо один из двух подходов (или двух проблем):
1. Отделение PHP кода от HTML кода.
либо
2. Отделение бизнес логики от логики отображения.
При чем, подчеркну, это не одно и то же. Первый подход это и есть путь FastTemplate, в шаблонах нет PHP кода, однако изменить логику отображения не удастся верстальщику не пнув программера чтобы тот внес изменения туда где в идеале должна быть только бизнес логика -- в коде PHP.
Второй подход -- это как раз Smarty и XSLT. В их шаблонах тоже нет PHP кода, однако логика отображения может менятся вне зависимости от программера с его кодом.
Конечно координация между верстальщиком и программером нужна всегда, вопрос лишь в том что во втором подходе они не координируют уже те вещи которые относятся (по крайней мере должны относится) только к одному из них. Например не будут таких запросов как "Верстальщик: мне нужно чтобы в переменную $color парсилось #FFF если ячейка четная и #000 если наоборот".

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

RaZEr

XML будет посложнее в реализации.

1. Мой XML'ный движок под саблотрон содержит 70 строчек кода (xml.lib.php). При этом для страницы выдающей HTML c основой иксэмэля такого вида:

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

PHP буквально следующий:

PHP код:

<?
require('xml.lib.php');

$xml = new block('page', array(
    element('class', 'topic'),
    new block('posts', array(
        new block('post', array(
            element('user', 'denver'),
            element('message', 'bla-bla-bla')
        )),
        new block('post', array(
            element('user', 'RaZEr'),
            element('message', 'RTFM')
        ))
    ))
));

echo $xml->output("/xsl/topic.xsl");
die("<!-- page generated ok -->");

Ну естественно в реальности масив заполняется в цикле, на основании данных из БД. Затем уже делается:
$page->include('posts', $posts);
$xml->include('page', $page);
или что-то типа того. Т.е. не так уж много кода, а XML тем не менее выдается валидный.
Понятно что результирующий HTML очень может даже походить на HTML страницы данного топика (чуть больше элементов добавить), но очевидно что код PHP все равно будет меньше чем если бы он был под FastTemplate (учитывая всю специфику imho.ws топика - вывод зебры, навигации, текущего раздела и т.п.).

То хостер консерватор-придурок не ставит нужные расширения

Это дело времени (или другого хостера).

то любимая программка не понимает UTF-8

О кодировке вообще речь не идет. XML и иже абстрактен от кодировок.

то клиент хочет сам редактировать HTML, при этом икая услышав "W3C Recommendation" или "Valid XHTML".

Если речь идет о некоей CMS то клиентский код вставляем обработав его htmlspecialchars(), сойдет т.к. придерживаться XHTML обязательно только в XSL файлах, а результирующий HТML может быть хоть трижды невалиден (при желании ).
Если же речь идет о том что клиент (зная HTML или наняв дешевого верстальшика) хочет править шаблоны, то тогда согласен, XSLT не подходит.

В любом случае (кроме последнего) все проблемы не являются боьльшими проблемами и решаются сегодня.

[denver]

Hubbitus
Да, чуть не забыл

Опять же очень актуальные проблемы с парсингом xhtml в Експлорере. Да и большой, очень огромный размер документов/шаблонов на XML тоже весьма не последний фактор помоему...

Касательно последнего. XML опять-же будет не шибко большим, т.к. не имеет избыточных данных и данных не имеющих отношение к результирующей HTML странице. А размер XSL шаблона не намного больше размера Smarty шаблона, конструкции действительно там чуть шире но ничего такого уж серьезного.

Из "актуальных проблем эксплорера" достаточно смирится только с тем что <script> должен иметь закрывающий элемент именно в виде </script> (да, это весьма в духе MS, но ведь не забил никто на CSS хоть и, помимо всех других, существует нехилая такая бага с боксовой моделью в IE5/IE5.5, ведь смирились как-то).

[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 да и еще много другого, стоит только поискать чуть-чуть...

[denver]

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

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

[Hubbitus]

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

denver:
Попробуй сам себе объяснить зачем кто-то там разрабтал Smarty, какую именно проблему он решал, почему много кто юзает Smarty, если уже давно была FastTemplate -- которая меньше и намного быстрее...

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

[denver]

Hubbitus

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

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

Еще раз напомню что их пока всего то и есть 2 рода темплейт систем.

[RaZEr]

Мой XML'ный движок под саблотрон содержит 70 строчек кода (xml.lib.php)

А движок по выводу php-Вставок занимает 0 строк. Это не показатель...

XML и иже абстрактен от кодировок

Особенно в PHP... как сейчас помню DOMXML и постоянные перекодировки тюда-сюда, потому что тут он берет только юникод, там отдает только его...

PS: Это конечно было пару лет назад, сейчас может дописали наконец.

а результирующий HТML может быть хоть трижды невалиден

Дело не в результирующем. То что клиент сам наредактировал должно быть перед XSLT, иначе весь этот код не будет трансформирован. А если с исходном XML для XSLT-процессора будет хоть одна ошибка, то он не сделает ничего. Хорошо хоть в пятерке валидатор встроили...

[denver]

RaZEr
Ты немного не понял принципа.

Валидный XML

<xml>&lt;table&gt;&lt;/tr&gt;</xml>

Валидный XSL

<xsl><h1><value-of select="/xml" /></h1></xsl>

Результат трансформации:

<h1><table></tr></h1>

ЗЫ. Ни о каких перекодировках не слышал, возможно потому что не использовал DOMXML

[RaZEr]

Да нет, немного не понял ты Мы пишем в XML ...

...<hr />...

далее XSLT делает нам красивую полоску например (!) так:

<hr class="primary" /><hr class="secondary" />

А если клент напишет не <hr /> а <hr> ... будет грустно.

Я понимаю что можно всё то, что написал клиент тихо запихать в CDATA, но тогда не сработает не одна из трансформаций, что в случае с CSM неприемлемо.

[denver]

RaZEr
Не мы друг друга не понимаем нифига
Мы не пишем в xml'е никакого HTML. А если и пишем то не обрабатываем его, а просто выводим (ну типа как через CDATA). А то это уже будет не темплейт систем, а... аналог CSS3 скажем, которое сделать тоже можно, но это оффтоп.

HTML выводящийся в XML в данном случае не часть оформления, а контент. Т.е. нет смысла в шаблоне шаблона сайта, этим не занимается и Smarty и т.п.

[Hubbitus]

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

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

[RaZEr]

Сообщение от denver

А то это уже будет не темплейт систем, а... аналог CSS3 скажем

Именно! Тем XSLT и хорош, что решает проблемы CSS 1&2. Нам ведь это и нужно (... решить все проблемы оформления). А приложение в свою очередь будет генерировать абстрактный XHTML, содержащий лишь информацию.

Сообщение от Hubbitus

кстати как ни странно нету у меня домашней странички

Нормальный порядок вещей. Мы же не сапожники

[denver]

Hubbitus

пока мало очень ясно и зачем, точнее в последнем свете поставновки вопроса: для каких конкретных целей, и как должно быть!

Так ты все же сначала разберись что ты хочешь-то дайте мне идеальную систему темплейтов и конечно быструю, и простенькую чтобы... FastTemplate!

RaZEr

Именно! Тем XSLT и хорош, что решает проблемы CSS 1&2

XSLT всем хорош. Но зачем упоминать все его достоинства если в рамках данного топика это оффтопик. Я думаю что и Smarty при желании можно делать то-же самое, только это никому особо не нужная функциональность.

[RaZEr]

Но зачем упоминать все его достоинства если в рамках данного топика это оффтопик

Почему же. Как раз наоборот. Это наш основной предмет разговора - полное и грамотное разделение оформления и содержания.

[denver]

Ко всем
Да, вот еще по теме. Никогда не следуйте примеру Sych

На локальной машине время генерации 1 мега XML + XSLT преобразование не превышает 0.1-0.3 се,обычные странички генерятся за 0.01-0.05 сек.

Для обработки мегабайтного XML (не важно каким XSL кодом) потребуется плюс минус столько же оперативной памяти сервера. Т.к. до любой обработки XML необходимо построить дерево его элементов, а формат XML файла далек от формата БД MySQL. Дерево будет строится в памяти, причем целиком, вне зависимости от того сколько элементов будет потом выбрано.

RaZEr
Так что ты хочешь сказать, что скажем Smarty наплевать на валидность/инвалидность значит он может заменить ...</p><hr><p>... на ...</p><hr class="primary" /><hr class="secondary" /><p>..., а XSLT не может? Ну если это принципиально то XSLT таки может заменить
...&lt;/p&gt;&lt;hr&gt;&lt;p&gt;... на ...</p><hr class="primary" /><hr class="secondary" /><p>... о чем речь?

О чем речь и нужно ли пытаться делать такие вещи даже в Smarty?

Это наш основной предмет разговора - полное и грамотное разделение оформления и содержания.

Если у нас сайт выводит помимо основного шаблона еще и текст пользователя оформленный как HTML, то этот текст по определению является контентом и значит по определению не должен включать элементы оформления. Ферштейн? Текст клиета обычно обрабатывается в момент получения от него данных, все тэги оформления и другие от которых может "поехать" дизайн всего сайта вырезаются. При желании сразу же делаем его валидным (не обязательно). Потом уже сохраняем в БД. Либо не заморачиваемся а делаем htmlspecialchars()