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

[Hubbitus]

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

1) И вот что мне во всем этом не нравится (например известный Smarty и еже с ним), сначала выполняется код на PHP, потом парсится шаблон, в него подставляются данные, а многие конструкции опять же переводятся в PHP и выполняются (если требуется конечно, например те же циклы) и только после этого все выводится...

Это же очень медленно, хотя и используются всякие методы вроде кеширования и прекомпиляции шаблонов...

2) Да и вообще, какая разница особенно, писать {CONTENT} или <?=$CONTENT?> ????

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

Итак главный вопрос: Стоит ли использовать специальные шаблонизаторы (или писать самому), если стоит то какие, на чем основанные, на каком принципе....

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

Всем заранее спасибо.

[is_absent]

Hubbitus
Лично я думал, что эти самые шаблоны нужны, чтобы облегчить жизнь верстальщику. Сделать как можно более привычным для его глаз синтаксис шаблона. человеку, который в глаза не видел PHP (имеется ввиду дизайнер, или верстальщик) будет не очень приятно разбираться в сложностях (с его точки зрения) php. Ему гораздо проще освоить новый язык разметки, тем более, похожий на HTML (это по пунктам 2 и 3).
С первым пунтком тоже согласен. На мой взгляд Smarty-подобные шаблоны слишком тяжелы, хотя и довольно функциональны.

Мой ответ -- если в вашей конторе есть дизайнер или верстальщик (то есть человек, который занимается внешним видом сайта), то шаблоны нужны.
Подходов несколько. Зависят от того, какие фунцкии ты хочешь иметь в своем шаблоне. самый минимум можно реализовать str_replace :)
для навороченных типа Smarty -- либо переводить код в php либо писать свой сканер и лезть в дебри синтаксических анализаторов (лично мне по душе больше второй вариант).

[Ale]

какая разница что ему учить?Это вы загнули батенька - PHP vs полтора десятка кодов

просто не трогать код PHP, а изменить только то что нужно по дизайнуПрограммист и дизайнер(верстальщик) как-бы не одно и тоже - нефиг маляру околачиваться в моторном отсеке и бадяжить машинное масло своими белилами цинковыми. Даже если выдрессировать маляра писать <?=$CONTENT?>, кто будет отвечать за последствия, а главное - их исправлять, маляр или программист?

Стоит ли использоватьСкорее нет, если такой вопрос возникает. Если не оч нужно, так и нефиг (дословнo - лучшее враг хорошего)

Мое имхо на этот счет:
- для своих сайтов я, ясен пень, не буду пользовать шаблонизатор
- если прийдется работать с кодером или для кодера - бессмысленно требовать от него бегом учить php. Шаблоны
- если буду сдавать движок стороннему заказчику, я туда не то что шаблонизатор, он-лайновый wysiwyg прикручу. Чтоб тока в код не лазили

Твой пост напомнил - что-то такое-же уже читал на xpoint - http://xpoint.ru/archive/threads/78/15670.html

[RaZEr]

если буду сдавать движок стороннему заказчику, я туда не то что шаблонизатор, он-лайновый wysiwyg прикручу. Чтоб тока в код не лазилиТы не видишь разницы между дизайном и содержанием. Заказчик дизайн должен будет рисовать в твоем wysiwyg?

[Hubbitus]

is_absent:
[дизайнеру] будет не очень приятно разбираться в сложностях (с его точки зрения) php. Ему гораздо проще освоить новый язык разметки, тем более, похожий на HTML
Вопервых для каждого сайта это может быть свой язык, черти что я могу написать для разных проектов... А во-вторых, возможно ему стоит объяснить просто что PHP это не так страшно, темболее что требуется-то в простейшем случае всего пяток конструкций элементарных знать...
is_absent:
либо переводить код в php либо писать свой сканер и лезть в дебри синтаксических анализаторов
Не совсем понял идею, синтаксический анализатор же всеравно что-то типа парсера, он выяснит какой алгоритм подразумевался под той или иной конструкцией абстрактного языка шаблонов, выполнить же его тоже кто-то должен...
Ale:
Это вы загнули батенька - PHP vs полтора десятка кодов
Ну извините, ктоже просит учить весь PHP, достаточно того же десятка конструкций в общем случае... Кстати в Smarty, например их гораздо больше....
Ale:
Программист и дизайнер(верстальщик) как-бы не одно и тоже - нефиг маляру околачиваться в моторном отсеке и бадяжить машинное масло своими белилами цинковыми.
Никто и не говорит что в общем случае это одно и тоже, в этом-то и главная проблема! Только вот где это разграничение цехов? А если внтри двигателя механику при сборке нужно что-то покрасить???
Ale:
Даже если выдрессировать маляра писать <?=$CONTENT?>, кто будет отвечать за последствия, а главное - их исправлять, маляр или программист?
А кто будет отвечать за последствия ошибок маляра в синтаксисе {CONTENT}? Странное сравнение...Ale:
если прийдется работать с кодером или для кодера - бессмысленно требовать от него бегом учить php. Шаблоны
Тоесть требовать от него выучить язык шаблонов это нормально, а 5 конструкций PHP, которые он сможет применять и дальше - черезчур?
Ale:
если буду сдавать движок стороннему заказчику, я туда не то что шаблонизатор, он-лайновый wysiwyg прикручу. Чтоб тока в код не лазили
Как правильно заметил RaZEr, Вы путаете некоторые понятия, одно другому не мешает. (Я же могу написать шаблоны и для смены внешнего вида WYSIWYG-редактора!)

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

[Ale]

1 - в случае шаблонов ты выдаешь только детальку покрасить, но не доступ к коду (самому отвинтить и привинтить). Соответственно, с шаблонами у пользователя несравнимо меньше возможностей что-то чисто случайно испортить. Дизайнер, котор, выучив десяток конструкций, будет считать что он разбирается в том-же php - это страшная сила. Не дай ему повод :)

2 - вообще-то я имел в виду шаблоны плюс wysiwyg, чтоб по максимуму ограничить позывы лезть в код (и php и html), бо контентом будет заниматься даже не дизайнер

[Hubbitus]

Ale:
1 - в случае шаблонов ты выдаешь только детальку покрасить, но не доступ к коду (самому отвинтить и привинтить).
А если мне нужно покрасить винтовое соединение, ну чтоб гайка не отвинчивалась, знаете? Тоесть я не могу открутить, покрасить, а потом прикрутить...
Ale:
Соответственно, с шаблонами у пользователя несравнимо меньше возможностей что-то чисто случайно испортить.
Вот это я совсем не понимаю, с чего это вдруг? Тоесть пример:
<html>
<head>
<title>{TITLE}</title>
</head>
<body bgcolor={BGCOLOR}>
{CONTENT}
</body>
</html>

Чем это интересно он защищеннее следующего?

<?include ('main.php')?>
<html>
<head>
<title><?=TITLE?></title>
</head>
<body bgcolor=<?=BGCOLOR?>>
<?=CONTENT?>
</body>
</html>

(В main.php cобственно b будут инициализироваться все нужные переменные)
Ale:
Дизайнер, котор, выучив десяток конструкций, будет считать что он разбирается в том-же php - это страшная сила. Не дай ему повод
Совсем не аргумент. А в том же легендарном Smarty часто, когда не хватает его функциональности, используя тег {php}...{/php} пишешь на PHP, для этого дизайнеру не полезно ли будет знать немного? Или тут нужно уже звать программиста? И вообще есть ли тут четкая грань? И потом не кажется ли Вам всем, что введение подобного тега разрушает всю концепцию раздельного дизайна???
Ale:
2 - вообще-то я имел в виду шаблоны плюс wysiwyg, чтоб по максимуму ограничить позывы лезть в код (и php и html), бо контентом будет заниматься даже не дизайнер
Для контента - да, WYSIWYG, но ведь не об этом речь же сейчас вообще!!!

[Ale]

Что-же тут непонятного? Даже в вашем примере вероятность что-то испортить значительно выше:
а) вы даете доступ к <?include ('main.php')?>, соотв даете доп возможность
б) вы увеличиваете объем кода на треть, соотв увеличиваете стат вероятность
Это есть объективные показатели, а аргументы против ссылаются на здравый смысл, уровень интеллекта, продвинутость дизайнера/верстальщика в кодинге, т.е. чисто субъективные факторы, котор собсно шаблоны и должны исключить насколь это возможно. Чтоб не искать грань меж пограммером и дизайнером (она объективно на разных уровнях для кажного случая), а задвинуть ея на более безопасную глубь. Это вообще-то 1 к 1 суть споров DOS/WIN, Perl/PHP

Насчет {php}...{/php} - это всего-то запасной вход для программера, не для дизайнера да еще 1 плюс к функциональности продукта. Он обязан быть в продукте уровня smarty

[is_absent]

Hubbitus:
Вопервых для каждого сайта это может быть свой язык, черти что я могу написать для разных проектов...
зачем каждый раз свой? один для всех.
Hubbitus:
Не совсем понял идею, синтаксический анализатор же всеравно что-то типа парсера, он выяснит какой алгоритм подразумевался под той или иной конструкцией абстрактного языка шаблонов, выполнить же его тоже кто-то должен...
естественно php. но уже сразу в результирующий html-код, без промежуточного "объектного-кода" PHP, как это делает тот же Smarty.
Ale:
б) вы увеличиваете объем кода на треть, соотв увеличиваете стат вероятность
наверняка вкючение кода шаблона будет производится внутри некоторого метода/функции, а не наоборот, так что про объем кода -- это не аргумент против. скорее даже за. поскольку общий объем шаблонов + его обработчика будет меньше. и разница будет расти прямопропорционально "крутости" шаблонов

[Ale]

is_absent:
так что про объем кода -- это не аргумент против. скорее даже за. поскольку общий объем шаблонов + его обработчика будет меньше. и разница будет расти прямопропорционально "крутости" шаблонов

Вообще-то речь об объеме кода, к которому имеет доступ непрограммист в случае неиспользования шаблонов (см. приведенный Hubbitus пример). Не об общем объеме шаблоны + обработчик

[is_absent]

Ale:
Вообще-то речь об объеме кода, к которому имеет доступ непрограммист в случае неиспользования шаблонов (см. приведенный Hubbitus пример). Не об общем объеме шаблоны + обработчик
это тоже спорный момент.
Мое личное мнение по поводу шаблонов -- они должны заниматься ТОЛЬКО представлением данных. большинство же существующих позволяют ИЗМЕНЯТЬ и СОЗДАВАТЬ новые данные. По-моему последнее не есть хорошо.

[Hubbitus]

Ale:
а) вы даете доступ к <?include ('main.php')?>, соотв даете доп возможность
Что значит "даю доступ" любой человек в здравом уме сможет запомнить что 1 строчку каждого файла шаблонов трогать нельзя :p
Ale:
б) вы увеличиваете объем кода на треть, соотв увеличиваете стат вероятность
Ну на треть увеличивается только в данном мизерном примере, для нормальной страницы в пару килобайт объем одна эта строчка увеличит объем на сотые доли процента - это не вероятность...

Остальные доводы трогать не буду, т.к. с объективными-то показателями не все в порядке...
Кстати совсем не понял аналогии с DOS/WIN, Perl/PHP.... :biggrin: Ale:
Насчет {php}...{/php} - это всего-то запасной вход для программера, не для дизайнера да еще 1 плюс к функциональности продукта. Он обязан быть в продукте уровня smarty
Оригинально, Вы же утверждали что нефиг маляру к механику в цех заглядывать, а механику значит можно беспредел творить? :)
is_absent:
зачем каждый раз свой? один для всех.
Тоесть дизайнеру достаточно выучить один всего язык шаблонов??? Может тогда кто-то мне подскажет какой? Что уже есть стандарт на это, или W3C что-то рекомендовал :) А пока дизайнер будет вынужден изучать каждый раз тот язык шаблонов, который в данной комманде разработчиков заложил в проект программист (только не нужно говорить что можно и договориться им вместе, общий же случай рассматриваем...)

is_absent:
естественно php. но уже сразу в результирующий html-код, без промежуточного "объектного-кода" PHP, как это делает тот же Smarty.
Да, но вместе с кешированием Smarty, это дает выполнение PHP-кода в последующие проходы, а при данном подходе всегда будет отрабатывать анализатор сперва... помоему не самый оптимальный путь...

is_absent:
Мое личное мнение по поводу шаблонов -- они должны заниматься ТОЛЬКО представлением данных. большинство же существующих позволяют ИЗМЕНЯТЬ и СОЗДАВАТЬ новые данные. По-моему последнее не есть хорошо.
Вот получается в ходе спора и еще один вопрос появился глобальный: а что же ДОЛЖНЫ шаблоны и что нет?

P.S. Вопросы только появляются :) :)

[is_absent]

Hubbitus:
Тоесть дизайнеру достаточно выучить один всего язык шаблонов??? Может тогда кто-то мне подскажет какой? Что уже есть стандарт на это, или W3C что-то рекомендовал А пока дизайнер будет вынужден изучать каждый раз тот язык шаблонов, который в данной комманде разработчиков заложил в проект программист (только не нужно говорить что можно и договориться им вместе, общий же случай рассматриваем...)
Предполагается, что человек работает в устоявшемся коллективе или по крайней мере мало изменяющемся. у которого уже есть некоторые правила общения/взаимодействия.Hubbitus:
Да, но вместе с кешированием Smarty, это дает выполнение PHP-кода в последующие проходы, а при данном подходе всегда будет отрабатывать анализатор сперва... помоему не самый оптимальный путь...
а анализатор + кеширование дает сразу "чистый" html.....

[Hubbitus]

is_absent:
Предполагается, что человек работает в устоявшемся коллективе или по крайней мере мало изменяющемся. у которого уже есть некоторые правила общения/взаимодействия.
Меня сейчас какраз больше интересует общий случай, а не частности. Например начиная новый проект использовать или нет шаблоны и какие, если использовать, чтобы потом наиболее просто было вливаться в него и программистам и дизайнерам...is_absent:
а анализатор + кеширование дает сразу "чистый" html.....
После выполнения на том же PHP, а так будет напрямую выполняться PHP-код и получаться "чистый" html, что несравненно быстрее.

[is_absent]

Hubbitus:
После выполнения на том же PHP, а так будет напрямую выполняться PHP-код и получаться "чистый" html, что несравненно быстрее.
я не совсем понял, что ты имеешь ввиду. Я говорил о преимуществе использования анализатора и кеширования перед Smarty + кеширование. Хранится уже результат работы. для анализатора -- это уже готовый HTML текст. если ты говоришь о том, что шаблоны которые используют <?=..?> работают быстрее - то с этим никто не спорил.

[plohich]

вы здесь сильно отвлеклись от темы, пошли в какието дебри теории, когда жизнь куда проще ))
рассматриваем приведенные выше примеры и смотрим на их плюсы и минусы.
1. <? include ('main.php');
ob_start("replace"); ?>
<html>
<head>
<title>{TITLE}</title>
</head>
<body bgcolor={BGCOLOR}>
{CONTENT}
</body>
</html>
<? ob_end_flush(); ?>
содержание main.php
<? function replace($buffer)
{
$buffer = str_replace("{TITLE}", "IMHO.ws", $buffer);
$buffer = str_replace("{BGCOLOR}", "#ffffff", $buffer);
$buffer = str_replace("{CONTENT}", "Greetings to all ::VIP::", $buffer);

return ($buffer);
} ?>

2. <?include ('main.php')?>
<html>
<head>
<title><?=TITLE?></title>
</head>
<body bgcolor=<?=BGCOLOR?>>
<?=CONTENT?>
</body>
</html>
содержание main.php
<?
$TITLE="IMHO.ws";
$BGCOLOR="#ffffff";
$CONTENT="Greetings to all ::VIP::";
?>

прошу прощения, если гдето ошибся :) но теперь перейдем к плюсам и минусам:

вся цель "раздельного питания" это обезопасить код, т.е. сделать ядро (которое вообще лучше закодировать ZE) и позволить пользователям делать максимум на остальном уровне, при этом чтоб уменьшить вероятность взлома. Хорошим примером этого является xNuke ( http://xnuke.info ).

берем возможность того, что стерли main.php. в первом варианте, в итоге мы увидим просто текст с {TITLE} и {CONTENT}, во втором же мы не увидим ничего или вообще получим ошибку. какой вариан лучше, решайте сами.

во втором варианте минусом можно посчитать излишнее создание переменных, в первом же варианте просто создается новый Markup Language.

думаю в этом направлении и стоит сранивать 2 эти примера.

p.s. в принципе, оба варианта создают разделение, просто разными методами. их оба можно сравнить с вариантом
<html>
<head>
<title>IMHO.ws</title>
</head>
<body bgcolor=#ffffff>
Greetings to all ::VIP::
</body>
</html>

[Hubbitus]

plohich:
вся цель "раздельного питания" это обезопасить код, т.е. сделать ядро (которое вообще лучше закодировать ZE) и позволить пользователям делать максимум на остальном уровне, при этом чтоб уменьшить вероятность взлома.
Тоесть все остальное не важно, производительность например? Хотя наконец-то кто-то обозначил более или менее цель этого всего. :yees:
plohich:
берем возможность того, что стерли main.php. в первом варианте, в итоге мы увидим просто текст с {TITLE} и {CONTENT}, во втором же мы не увидим ничего или вообще получим ошибку. какой вариан лучше, решайте сами.
В готовом проекте можно просто отключить вывод сообщений об ошибках и в этом примере во втором варианте мы получим просто <title></title> а в первом еще и выведем информацию которая может помочь злоумышленникам во взломе, это уж если говорить о безопасности.
plohich:
во втором варианте минусом можно посчитать излишнее создание переменных, в первом же варианте просто создается новый Markup Language.
Ну если излишнее создание переменных минус, то можно сделать один массив... А вот о целесообразности создания нового Markup Language я и поднял вопрос, и на протяжении всего этого топика его пытаемся со всеми решить!!! :biggrin:
plohich я так и не понял твоего мнения по этому поводу, как делать "правильнее" и почему? Сравнивая эти варианты, к чему ты пришел, какой лучше (или может третий какой-то)?

[plohich]

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

[dacuan]

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

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

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

Я предпочитаю использовать синтаксис вида <?=$title?>, по нескольким причинам. Во-первых, так сложилось исторически. Во-вторых, они работают быстрее. В третьих, часто мне приходится самому писать шаблоны на основе HTML-кода, который мне дает верстальщик, и мне гораздо проще работать именно с таким синтаксисом.

Правда, в последнее время, все чаще смотрю в сторону связки XML/XSLT, в этой ветке такой подход еще не обсуждался. Система шаблонов XML/XSLT имеет следующие преимущества:
1) Нет проблемы переписать серверное приложение на другой язык, шаблоны менять не придется, практически во всех современных языках поддерживается работа с XML/XSLT.
2) Упрощается обмен информацией между верстальщиком и программистом. Верстальщик отдает программисту XSLT и DTD, согласно которому программис будет создавать XML-документ.
3) Используя XSLT можно легко менять формат выходного документа, от HTML и WML, до PDF, PS DVI и проч.

Если кто сталкивался с подобным подходом к шаблонам, буду рад услышать мнение о нем.

[Hubbitus]

Мне досих пор тоже было удобнее писать типа <?=$title?>, но я наконец решил что нужно поразбираться в альтернативных схемах.

dacuan:
Правда, в последнее время, все чаще смотрю в сторону связки XML/XSLT, в этой ветке такой подход еще не обсуждался. Система шаблонов XML/XSLT имеет следующие преимущества:
1) Нет проблемы переписать серверное приложение на другой язык, шаблоны менять не придется, практически во всех современных языках поддерживается работа с XML/XSLT.
2) Упрощается обмен информацией между верстальщиком и программистом. Верстальщик отдает программисту XSLT и DTD, согласно которому программис будет создавать XML-документ.
3) Используя XSLT можно легко менять формат выходного документа, от HTML и WML, до PDF, PS DVI и проч.

Если кто сталкивался с подобным подходом к шаблонам, буду рад услышать мнение о нем.
1) При правильном шаблоне итак не будет проблем переписать под другой язык, шаблон также не придется менять, не вижу здесь проблемы.
3) - это бесспорно огромный плюс.
А теперь о всей этой технологии в целом, впринципе она конечно неплоха, НО, во-первых XML код обычно на порядок больше места занимает по сравнению с другими способами. Во-вторых - поддержка XML/XSLT в разных языках может все-таки различаться. И в третьих - я понимаю конечно, что можно написать все, в т.ч. хранить данные в БД, а потом их конвертировать в промежуточную форму (XML например) но ведь это изврат помоему, да и долго. А хранить большие объемы данных в XML - тоже убийственно, поэтому это не может заменить БД в любом случае.
Мне кажется что третье наиболее существенное препятствие.

[dacuan]

1) При правильном шаблоне итак не будет проблем переписать под другой язык, шаблон также не придется менять, не вижу здесь проблемы.
Я имел в виду, что придется переписывать и шаблонный движок. Само-собой, в этом случае шаблоны переписывать не придется.
во-первых XML код обычно на порядок больше места занимает по сравнению с другими способами
Это верно, но во-первых можно поизвращаться, поудалять лишние пробелы и т.п. Для примера можно посмотреть формат файлов OpenOffice.
Во-вторых, XML можно рассматривать как участок PHP-кода, в котором происходит занесение переменных в шаблон (те самые assign()) и я не думаю, что такие два подхода будут сильно разнится в размерах, но остается открытым вопрос скорости, нужны бенчмарки.
В-третьих, собранный XML пожно использовать как один из уровней кеша. Это может быть удобно при реализации двух версий сайта HTTP и WML, когда наполнение одно и то же, но разнятся форматы отображения.
Во-вторых - поддержка XML/XSLT в разных языках может все-таки различаться.
XML/XSLT это уже признанный стандарт с четкими RFC и я не думаю, что различные реализации не поддерживают RFC. В ПХП есть возможность использовать libxml, libxslt, эти же библиотеки можно использовать и на перле и на си, думаю, есть и возможность прикрутить ее к asp и иже с ними, хотя в нем есть своя реализация xml.
И в третьих - я понимаю конечно, что можно написать все, в т.ч. хранить данные в БД, а потом их конвертировать в промежуточную форму (XML например) но ведь это изврат помоему, да и долго.
Генерация XML не займет времени дольше, чем генерация HTML со вставками вида <?=title?>. Возможно, получится генерацию ускорить за функций для работы с DOM XML, но опять же нужны тесты. Так что, с определенной точки зрания, генерация HTML и генерация XML одно и то же, разве что структура XML будет проще, так как нет необходимости вставлять теги форматирования, следить за структурой таблиц и проч.
Но добавляется еще один этап при генерации шаблона - преобразование XML->HTML с помощью XSLT, так что использование XML для реализации шаблонов будет чуть медленнее, чем прямая генерация HTML. С другой стороны имеем ускорение разработки, за счет упрощения взаимной работы верстальщика и программиста и упрощается поддержка проекта, так как шаблонизатор стандартный (гораздо распространеннее FastTemplate, Smarty и проч.)

[Hubbitus]

Шаблонный движок переписать конечно придется, в этом неоспоримое преимущество стандартизированного XML.
dacuan:
Это верно, но во-первых можно поизвращаться, поудалять лишние пробелы и т.п. Для примера можно посмотреть формат файлов OpenOffice.
Насколько Вам известно, OpenOffice хранит свои файлы в XML, сжимая их архиватором, конкретно GunZip'ом. Это же неприемлемо для Веб-сайта с нормальной посещаемостью (даже если выделенный сервер не вижу причин так понапрасну расходовать процессорное время).
dacuan:
В-третьих, собранный XML пожно использовать как один из уровней кеша. Это может быть удобно при реализации двух версий сайта HTTP и WML, когда наполнение одно и то же, но разнятся форматы отображения.
Когда требуется такой уровень кеша, который по структуре подходил бы к разным представлениям - ничего не могу сказать - не знаю, не сталкивался, но для каждого конкретного случая в отдельности можно реализовать куда более оптимальный способ представления кеша.
dacuan:
XML/XSLT это уже признанный стандарт с четкими RFC и я не думаю, что различные реализации не поддерживают RFC.
:biggrin: HTML, DOM и CSS уже сколько лет стандарты, а поддержку одинаковую у разных браузеров все также ждут миллионы программистов/верстальщиков по всему миру :biggrin: Что касается XML - я НЕ сравнивал, и НЕ знаю о различиях реализации, но подозреваю что и тут камней будет море.
Может кто-то поделиться своим опытом в данном вопросе?

Ну дак и какой вывод из последнего абзаца? Жертвуем производительностью ради удобства верстальщика (кстати весьма сомнительного, потому что изучать ему всеравно придется что-то)?

[dacuan]

Насколько Вам известно, OpenOffice хранит свои файлы в XML, сжимая их архиватором, конкретно GunZip'ом. Это же неприемлемо для Веб-сайта с нормальной посещаемостью (даже если выделенный сервер не вижу причин так понапрасну расходовать процессорное время).
Если быть точным, то в архиве несколько файлов XML, и не только они. Я имел в виду организуцию XML-фалов (в них все лишние пробельные символы удалены) но не достижение сверхмалого размера за счет архивирования.
Когда требуется такой уровень кеша, который по структуре подходил бы к разным представлениям - ничего не могу сказать - не знаю, не сталкивался, но для каждого конкретного случая в отдельности можно реализовать куда более оптимальный способ представления кеша.
Согласен, но такая функциональность скорее следствие, а не первопричина выбора технологии.
HTML, DOM и CSS уже сколько лет стандарты, а поддержку одинаковую у разных браузеров все также ждут миллионы программистов/верстальщиков по всему миру.
Основная проблема несовместимости браузеров не в том, что они не поддерживают стандарты (стандарты в каждом браузере реализованы полностью), а в том, что каждый браузер по своему воспринимает отхождения от стандартов, хотя это мое ИМХО.
Что касается XML - я НЕ сравнивал, и НЕ знаю о различиях реализации, но подозреваю что и тут камней будет море.
Именно поэтому я и упомянул о библиотеках libxml и libxslt.
Ну дак и какой вывод из последнего абзаца? Жертвуем производительностью ради удобства верстальщика (кстати весьма сомнительного, потому что изучать ему всеравно придется что-то)?
Именно так, при условии, что потери производительности не будут колоссальными ;) . Ведь все с удовольствием пользуются фабриками классов, не смотря на то, что они отрабатывают в разы медленнее, чем прямое создание объектов. Да и, как видно из ветки, люди согласны жертвовать производительностью при выборе механизма шаблонизации, разница лишь в том, что шаблонизация с использованием XML, более общее решение, чем большинство шаблонных движков.

[Hubbitus]

dacuan:
Если быть точным, то в архиве несколько файлов XML, и не только они. Я имел в виду организуцию XML-фалов (в них все лишние пробельные символы удалены) но не достижение сверхмалого размера за счет архивирования.
Я и написал файлЫ, но дело не в этом, удаление пробелов - это лишь капля в море, проблема "большого объема" остается весьма насущной при интенсивном использовании.

Про функциональность в целом и совместимость такого подхода с использованием XML, я и не спорю. Меня инетерсуют также и другие факторы, и насколько "плюсы" перекрывают "минусы"!
dacuan:
Основная проблема несовместимости браузеров не в том, что они не поддерживают стандарты (стандарты в каждом браузере реализованы полностью)
Ой, вот тут Вы не правы!!! Лучше всех стандарты поддерживает Мозилла (моя личная оценка процентов на 90-95), опера достаточно неплохо их поддерживает но далеко не полностью, а вот с ИЕ, если Вы пробовали хоть что-то сделать по стандартам - начинается полный разброд!!!!! (Только умоляю всех, давайте не будем здесь обсуждать конкретно браузеры и их совместимость, ведь всем прекрасно известно что, например DOM2, ни у одного браузера не реализован в полном объеме :) )
dacuan:
Да и, как видно из ветки, люди согласны жертвовать производительностью при выборе механизма шаблонизации, разница лишь в том, что шаблонизация с использованием XML, более общее решение, чем большинство шаблонных движков.
Я не заметил в данной ветке всеобщего одобрения такой "жертвы". Всем же хочется найти эту золотую середину между жертвами и полученным преимуществом. Причем эти преимущества для каждого свои, а многие подразделяют еще и проекты, для которых приемлемо то или иное решение.

P.S. Наконец я осознал необходимость использовать шаблоноподобные подходы, только досих пор не могу понять на чем и как строить наиболее оптимальное решение.

[ctapuk]

вот в перле есть пара удобных шаблонных движков, HTML::Template
и template-toolkit.org. Я приспособился на втором генерить код в cgi CMS,
в который потом вставляется php :) Работает удобно :)

[Hubbitus]

Шаблонных движков куча, и не про них вообще речь идет, а о идеологии и принципе построения.

А генерить на Перле код, в который потом вставлять ПХП - IMHO, изврат.

[dacuan]

Я и написал файлЫ, но дело не в этом, удаление пробелов - это лишь капля в море, проблема "большого объема" остается весьма насущной при интенсивном использовании.
Проблема становится насущной только при наличии фактов, подтверждающих, что увеличение лишнего объема существенно повлияет на производительность. Да и отношение объема тегов к объему полезного контента, в общем случае, будет невелико.
Меня инетерсуют также и другие факторы, и насколько "плюсы" перекрывают "минусы"!
Как я и писал в своем первом посте:
Если кто сталкивался с подобным подходом к шаблонам, буду рад услышать мнение о нем. ;)
Ой, вот тут Вы не правы!!! Лучше всех стандарты поддерживает Мозилла (моя личная оценка процентов на 90-95)
Я же предупреждал, что это - мое ИМХО :)
Я не заметил в данной ветке всеобщего одобрения такой "жертвы".
Разве факт того, что человек использует шаблонный движок, не есть его согласие на "жертву"? ;)
P.S. Наконец я осознал необходимость использовать шаблоноподобные подходы, только досих пор не могу понять на чем и как строить наиболее оптимальное решение.
Подведем итог.
Предложенные технологии:
1) Синтаксис ПХП.
- плюсы - быстрый не требуется переучиваться, большая функциональность и поддержка всех возможностей ПХП;
- минусы - нечеткое разделение кода и дизайна, слабая переносимость шаблонов (при реализации проекта на другом языке, шаблоны придется переделать).
2) Стандартные шаблонизаторы (Smarty, FastTemplate)
- плюсы - более сильное разделение дизайна и кода;
- минусы - не так быстры, как синтаксис ПХП, при переносе проекта необходимо будет кроме основного кода переносить и шаблонный движок.
3) XML/XSLT
- плюсы - полное разделение дизайна и кода, хорошая переносимость (работа с XML/XSLT реализована в большинстве современных языков);
- минусы - неясен вопрос производительности (по крайней мере для меня), вводится промежуточный способ хранения данных (XML).

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

[Hubbitus]

dacuan:
Разве факт того, что человек использует шаблонный движок, не есть его согласие на "жертву"?
Нет, это может быть продиктовано лишь необходимостью! Если ему предложить вариант лучше - то наверное он перейдет, вот только его поиск, этого варианта оакзывается весьма сложен, как я погляжу...

Итог Вы подвели очень неплохо, действительно хотелось бы собрать побольше статистики, основанной на опыте..

[dacuan]

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

Кстати, не учел еще один вариант:
4) Шаблон с произвольным синтаксисом конвертируется в шаблон с синтаксисом ПХП

[Hubbitus]

dacuan:
Кстати, не учел еще один вариант:
4) Шаблон с произвольным синтаксисом конвертируется в шаблон с синтаксисом ПХП
Я думаю это наиболее правильный вариант для представления кеша шаблонов, если уж не получится сделать его статическим.

[dacuan]

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

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

Можно, конечно, после компиляции шаблонов их еще и через ZendEncoder прогнать, но какая-то длинная цепочка получается, да и Zend Encoder не совсем бесплатная программка, к тому же требует наличие ZendOptimizer'а на сервере.

[Hubbitus]

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

[dacuan]

Очень надуманный пример. Программер глупый чтоли????
Глупый, невнимательный, ленивый можно назвать как угодно, но, учитывая, сколько раз я сталкивался с ситуацией, когда перед экспериментами с базой данных не делали ее дамп и теряли большую часть информации, можно предположить что программер просто поленится сделать все по уму.
Риск возникновения ситуации остается и приходится вспоминать Закон Мерфи: "Если существует вероятность допустить ошибку в настройке прибора, техник ее обязательно допустит". В нашем случае руками поправит шаблон.

[RaZEr]

А какой резон делать преобразование my_template->php_template в час икс? Это обычно делается по нажатии кнопки "сохранить шаблон" в веб-интерфейсе системы. И кэша в данной ситуации просто нет.

[Sheryld]

имхо, для php4 в любом случае нужно использовать HTML, по причине того, что XML/XSLT там поддерживается экспериментально, и не все функции удовлетворяют стандартам DOM. к тому же это банально неудобно(именно в php4).

последний месяц использую: KTemplate (http://kuerbis.org/template/) вместе с php4.

плюсы:
+очень легкий и небольшой класс
+возможность делать шаблон в одном файле, т.е. допустим нужно "раскрасить html"(вполне стандартная задача). KTemplate позволяет задать возможные куски в одном файле. На php остается только распарсить и соединить нужные блоки.
+полное отделение кода от представления

в php5 появились действительно полезные возможности, например simpleXML, с которым работать одно удовольствие. тут уже можно серьезно заняться решением: XML|XSLT. Пример недавно был приведен в этмо форуме.

[Vtl]

Привет.


1. Вообе-то поставленный вопрос (об использовании шаблонизаторов) становится неактуальным если верстальщик (верстальщики) и программист (программисты), работающие над проектом, очень хорошо знают свое дело. В этом случае хотя и получается изобретение велосипеда, но этот велосипед ездит быстро и не ломается.
2. К тому же, че универсальнее инструмент (Smarty, например) для работы с другими инструментами (php+mysql+html+css+js...), тем больше вероятность нестабильной работы объекта (web-приложение), который с помощью этих инструментов создан. И, да простят меня модераторы за маленький флуд, если Вы используете все эти инструменты и у Вас все работает быстро и корректно - значит Вы постигли Дао web-разработки и к Вам применим пункт 1. :biggrin:

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

Мое субъективное мнение. :rolleyes:

[Hubbitus]

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

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

[ReapeR]

почитал я эту ветку и вот чего подумал:
можно же написать прогу (хоть на дельфях, хоть на том же php) которая будет менять {Сontent} в шаблоне на <?=$Content?> и записывать полученный файл на сервак, причем ни программер, ни верстальщик не будут видеть/редактировать полученный файл. Получается этакий компромис.

[dacuan]

ReapeR
Этот вариант рассматривался выше и отмечалась некотороя сложность с поддержанием соответствия локальный файл -> шаблон и отсутствие (или почти отсутствие) возможности запретить прямое редактирование откомпилированного шаблона.

[Sheryld]

сейчас буду первый раз использовать систему xml+xslt+php5+база данных
система такая:

есть бд(данные)

есть формат данных(в xml)+шаблон(ы) в xslt.

при редактировании базы данные меняются:

1. в базе.
2. пересоздается xml-файл.

при запросе всегда выдается: xml+xslt => html.

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

[dacuan]

Sheryld
Было бы интересно увидеть результаты эксперимента :)

[Sych]

результат на лицо http://sybe.dotgeek.org/ время генерации говорит за себя :-)

[dacuan]

Sych
Время генерации, минимум 0.014, максимум 0.9
Не лучшие показатели :\ На каком сервере стоит система?....

[Sych]

Сейчас все работает на забугорном халявном хостинге так что как говорится системка показывает себя в боевых условиях тк на этом же сервере хостится еще около 5000 проектов.

Время генерации варируется в широких пределах в зависимости от загружености машинки и частоты обращения к этому проекту.

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

Хотя я сомневаюсь что в реальных условиях будут файлы такого размера.

Система пока сырая - но дает представление о своей работе и потенциале.

Кому интересно могут написать в приват - Я дам потестить, для работы надо php5.

[Hubbitus]

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

Плюс неоспоримым преимуществом является конечно то что я могу реализовать впринципе любую необходимую конструкцию в нем, а не только тем пользоваться что мне предлагают. Предвосхищая крик многих типа "а в подходе ХХХ уже все это есть и предусмотрено" хочу спросить сколькими вообще возможностями из имеющихся там Вы пользуетесь обычно, и сколько процентов из общего числа Вы использовали хоть раз?! :) А время-то на обработку и условия тратится...

Да и потом как же быть с тем так и не закрытым вопросом должен ли Дизайнер (верстальщик) учить новый язык, например XML? Какая разница, почему бы ему в таком случае не выучить 20 конструкций PHP? :)

Вобщем мне в любом случае оказалось приятнее своя реализация. Как говорится "своя рубашка ближе к телу". Это конечно не аргумент, но это крайне важно, когда нужно решить нестандартные задачи....

[Sheryld]

KTemplate. использую на 100%.

хотя есть и свои наработки.

[MOP]

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

проект где-то до 50 страниц (например сайт знакомств или форум): можно использовать подход header-body-booter. тобишь общие части просто загнать в отдельный файл и вставлять его на каждой странице.
Коенчно, в этих двух случаях вы не увидете никакого разделения дизайна и кода, и это перекроет возможность кодеру прикрутить дизайн к программе самостоятельно, но даже если программист сам это сделает, выигрышь времени будет на лицо.
Использовать шаблоны я бы рекомендовал только в больших проектах (более 50 страниц). Еще один огромный плюс шаблонов: при условии удачного соглашении об именовании переменных, методов и классов и использовании ООП вместе с шаблонами, проект выполненный с использованием шаблонов дает преимущество в поддержке.

[Hubbitus]

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

[RaZEr]

проект страниц на 10 не больше (есть и такие, например порно сайт)Порно сайт в 10 страниц ... 5 превью и 5 - биллинг :ржать:

[Ruferut]

Я использую php_templates и chtemplate.
Оба движка работают как extension к php, поэтому скорость работы по сравнению с самим пхп (<?=$content?>) практически минимальна (т.е. почти нет вообще). По сравнению с аналогами (smarty, fasttemplate, xtemplate даже при использовании ими кэширования) генерация с помощью этих движком происходит в разы быстрее. В php-templates правда тоже встроен механизм кеширования в вирт. памяти.
За то плюсы на лицо: быстрая генерация страницы, полное разделение дизайна от кода.
Минусы: то что используется как библиотека, поэтому надо просить хостера чтоб установил.

[Hubbitus]

Ruferut:
поэтому скорость работы по сравнению с самим пхп (<?=$content?>) практически минимальна (т.е. почти нет вообще). Это круто сказано, конечно можно догадаться что имелось ввиду, но написано что "скорость работы минимальна, тоесть вообще не работает" :ржать:

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

Итак, мне все-таки пришломь разбираться со Smarty в одном из проектов (многим известный X-Cart Gold), приведу пример шаблона на смарти:
{section name=cat_num loop=$categories}
{capture name=block}
{section name=cat_n loop=$categories[cat_num].sub}
• <a class="leftLinks" href="home.php?cat={ $categories[cat_num].sub[cat_n].categoryid }"> { categories[cat_num].sub[cat_n].category|escape }</a><br>
{/section}
{/capture}
{include file="block.tpl" title="<a class=insideTitle3 href=home.php?cat=`$categories[cat_num].categoryid`>`$categories[cat_num].category`</a>" content=$smarty.capture.block extra="class=bgInside5"}
{/section}

Это простенький (!), полностью реальный, работающий шаблон с сайта, для формироания списка категорий в магазине, включающийся в остальные страницы.
Итак главный вопрос: Это наглядно для дизайнера, не разбирающегося в программировании вовсе???? Это реализует концепцию разделения кода и содержания?
Только не нужно говорить, типа "и не нужно использовать Смарти, вон в ХХХ все наглядно и просто", когда шаблонизатор обрастает возможностями и функциональностью, его синтаксис неизменно усложняется, с этим, надеюсь, никто спорить не будет. Тоесть, при том что я сам написал шаблонизатор для собственного использования, и мне с ним удобнее теперь работать, я никак не могу нормально разобраться во всем этом принципе: как же это все должно быть в идеале....

[Sheryld]

у каждого свой идеал. вместо "навороченных" шаблонов нужно использовать xslt. там это все уже есть и даже больше.

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

мне нравиться делать следующим образом:

есть шаблон. вся его обработка идет в коде. пример:


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


Вся обработка идет в php.

1. разделение кода.
2. простота.

p.s. мне идеально подошел KTemplate.

[RaZEr]

вообще верстку должен делать не дизайнер, а верстальщик, а у него должна быть некоторая подготовка.Не согласен. Дизайнер задумывал дизайн и соответственно он сверстает лучше кого бы то нибыло. А как внедрить это вопрос к разработчикам тех. части (хотя часто всё обходится header-footer заменой).

[Sheryld]

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

у тебя есть картинка, макет, описание и т.д.
твоя задача выдать тоже самое, но в html.

[Hubbitus]

Ребята, ребята, не стоит об этом спорить :beer: , неважно кто будет делать верстку дизайнер или верстальщик, вы мне лучше ответьте на другой вопрос, что значит

Sheryld:
у него должна быть некоторая подготовка.
???
Вы считаете что он должен в любой момент кидаться изучать как программисту в очередной раз Sheryld:
нравиться делать следующим образом, в очередном проекте, и не важно совсем что это будет: Smarty, xslt, KTemplate или многие, многие другие?

И вот теперь, тут, мы возвращаемся к самому моему первому и принципиальному вопросу, заданному в самом начале этой темы, и как-то оставленном посути в стороне, отвлекаясь на всякие частности, на альтернативы и т.д.: А не проще ли Дизайнеру (пусть верстальщику) выучить десяток-два конструкций на PHP, тех что ему необходимы для верстки??? Это не универсальнее вообще? Тоесть разделение возможно и нужно, но нужно ли его делать "полным" и для этого изобретать велосипеды и новые технологии, кому какие вздумается?

[Sheryld]

еще раз и все по-порядку.

1. я уже давно не делаю вставок php кода в html. просто считаю это не правильным подходом. отсюда и идут шаблоны(при всех остальных плюсах). более того, там где это возможно(по срокам) стараюсь всегда делать четкое разделение приложения на уровни(data layer, biz, logic, output, etc).

обычно у меня так:

1.база данных.
2.класс, инкапсулирующий всю логику.
3.сборка страницы.
4.шаблон.

уровни могут "общаться" только с соседними.

если нету времени, 2-ой уровень убирается.

2. xslt это язык программирования. дизайнер его знать не обязан, а хорошему верстальщику - самое оно.

3. ответ на твой вопрос для меня очевиден: не проще и не правильно.

[Hubbitus]

Sheryld:
1. я уже давно не делаю вставок php кода в html. просто считаю это не правильным подходом.
"просто неправильный подход" давай остаим в детском саду ответ, ок?
Sheryld:
если нету времени, 2-ой уровень убирается.
Гы, самое главное, логика приложения убирается??? Оригинальный подход. И потом разве БД не входит в 2, ведь для обеспечения логики работы с данными она какраз и используется...

Sheryld:
2. xslt это язык программирования. дизайнер его знать не обязан, а хорошему верстальщику - самое оно.
Тоесть ты настаиваешь, что если верстальщику (ну пусть, раз именно тебе так хочется, верстальщику, хотя я согласен с RaZErом и никак не могу понять почему принципиально дизайнер не может сверстать), чтобы нормально работать с тобой нужно знать XSLT? А потом он со мной будет работать, я а скажем (пример), Смарти люблю, то и его ему узнать "самое оно"? А с Петей программистом, которому, скажем, KTemplate нравится, тут уже он "самое оно"??? Тоесть получатся программистам в простейшем случае (не нужно утрировать и придираться, я вобщем говорю) нужно знать только PHP, а бедному верстальщику изучать каждый раз то что программисту придет в голову???

Sheryld:
3. ответ на твой вопрос для меня очевиден: не проще и не правильно.
Смотри самое начало этого поста.

[Sheryld]

2Hub

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

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


class Item extends AbstractItem //base item
{
var $itemInfo = array(
'id'=>0,
'catid'=>0,
'title'=>''
);

var $itemCollection = array();
.
.
.
function GetItemById($itemID)
{
$db = new MySql(null,null,null,null);
$db->MySql_Connect();
$db->MySql_SelectDb();

$selectQuery = "select itm_ID, cat_ID, itm_TITLE from cat_item where itm_ID = " . $itemID . " limit 1";

$db->MySql_QueryDb($selectQuery);

if ($db->dbResult != null)
{
while($row = mysql_fetch_assoc($db->dbResult))
{
$this->itemInfo['id'] = $row['itm_ID'];
$this->itemInfo['catid'] = $row['cat_ID'];
$this->itemInfo['title'] = $row['itm_TITLE'];
}
return 0;
}

return -1;

}

.
.
.
}


страница "x" будет в таком случае следующей:


$item = new Item(); //default constructor
if ($item->GetItemById(1) == 0)
{
print_r($item->itemInfo);
}


в чем суть?

в том, что страница "x" ничего не знает ни о бд, ни о запросах, вообще ни о чем, вся ее задача это вывести данные на экран.

при подобной архитектуре, приложение становится очень гибким, а код можно реалньо использовать во множестве проектов, т.к. нужно будет менять только вывод(HTML, XML, ETC).

если же нету времени, то я переношу логику на 3-ий этап.

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

про дизайнера - я все написал. добавить мне нечего.

p.s. в данном случа программист должен будет распарсить шаблон, а верстальщик собвственно их сделать.

пример опять же:

дизайнер сделал макет, эских или предвариетльную верстку:

элемент "список"

верстальщик сделал:


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


программист(псевдо шаблонизатор):


$listTpl = $tpl->fetchblock("list");

foreach($item->itemCollection as $itemObject)
{
$listItemTpl = $listTpl->fetchBlock(list_item);
$listItemTpl->assign("item_title",$itemObject["title"]);
$listTpl->assign("list_item",$listItemTpl );
$listItemTpl->reset();

}

$tpl->assign("list",$listTpl);

[Hubbitus]

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

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

Итак, приведенный тобой код того что "верстальщик сделал" так красив просто и понятен только пока .... он так прост! Я же привел пример к чему приводит наращивание возможностей, на примере Смарти. А подобного не избежать никак помоему - полюбому и верстальщику нужно будет все больше возможностей и универсальности... Дак вот где здесь компромисс??

[Aeon]

Здесь есть ещё неплохая статья на эту тему (но на английском).
http://www.massassi.com/php/articles/template_engines/

[shuron]

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


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

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

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

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

[denver]

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

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 в Експлорере (http://xpoint.ru/forums/thread/25797.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 буквально следующий:

<?
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 в Експлорере (http://xpoint.ru/forums/thread/25797.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]

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

...<hr />...

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

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

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

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

[denver]

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

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

[Hubbitus]

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

[RaZEr]

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

[denver]

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

RaZEr
Именно! Тем XSLT и хорош, что решает проблемы CSS 1&2XSLT всем хорош. Но зачем упоминать все его достоинства если в рамках данного топика это оффтопик. Я думаю что и 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>... о чем речь? :confused:

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

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

[y13]

Полное и грамотное разделение оформления и содержания, можно добиться только правильной организацией процесса разработки. И тут уже сугубо по барабану, какую технологию вы используйте – да хоть ручками вставляйте. Главное – чётко, по полочкам разделить обязанности всех участников процесса. Дизайнер рисует, на этом его круг обязанностей заканчивается окончательно и бесповоротно. Ведущий программист, проектирует бизнес логику, раздаёт задания программистам и координирует процесс производства продукта. Программист занимается реализацией заданной бизнес логики, подготавливает конечный продукт.

Цепочка получается простая: Вася - ведущий программист, придумал гостевую книгу, дал задание Пете программисту и Маше дизайнеру. Пете – реализовать предоставленные алгоритмы; Маше – нарисовать интерфейс. И Маша, и Петя сдают работу Васе. Вася принял макет Маши, передал этот макет Пете. С макетом Петя получил ещё и инструкции от Васи, в которых чётко расписано, что и как надо делать с макетом.

Оформление от Маши, движок от Пети, а содержимое от клиента (он же – конечный потребитель созданного блага). Вот это – полное и грамотное разделение оформления и содержания. Маше, Васе и потребителю до лампочки, что там использовал Петя: FastTemplate, Smarty, XML, HTML::Template или ещё какую технологию. Это заботы конкретно Пети. Хотя тут и забот-то нету – выбрал то, что тебе нравится, и всем предоставленным требованиям отвечает .

Не могу понять, почему вы до этого так долго идёте? Судя по тому, что тут было написано, ни одного крупного коммерческого проекта никто не писал. А если и писали, то организация этого проекта оставляет желать лучшего. Попробуйте свою точку зрения, положить на масштабы того-же Microsoft'a и представить, как бы ваша логика работала в их рамках. А там надо не 10 и 20 человек организовать… Вот уж кто Вильям Гейтс, так это прирождённый IT-менеджер.

А теперь в тему.

Технология шаблонизции данных, нужная и полезная вещь, которая позволяет не мешать Маше и Пете выполнять свои непосредственные обязанности и помочь менеджерам отделить мух от котлет. В свою очередь, заблуждения о том, что шаблонизатор A, хуже чем B, потому что, он не умеет делать … вообще безосновательны. Каждая система пишется с учётом определённых требований и не может быть использована для любого проекта. Только поэтому выбор этих самых шаблонизаторов такой широкий, ибо не каждому подходит A, потому что он …, … и …

Сегодня время Smarty и FastTemplate, завтра XML, послезавтра ещё чего-то, т.к. возможностей первых двух хватает на сегодняшний день. Мне например обе эти системы не подходят из-за их «навороченности». Никакой шаблон недолжен нести код. Мы помним, что этот самый шаблон рисовала Маша, а она ни php, ни perl даже в глаза не видела - У неё есть 8Mpx цифра, яблочный комбайн, ручки и хорошие способности к рисованию. А вот Петя, уже должен суметь без запускания пальцев в исходный макет (идеальный вариант) написать систему, которая этот конкретный макет будет использовать. Вот XSLT в полной мере позволяет решить проблему запуска ручек Петей в Машину работу, окончательно закрыв этот топик, а Smarty и FastTemplate заставляют Петю лазить по Машиной работе, вставляя туда шблонизаторскую разметку.

[RaZEr]

Так что ты хочешь сказать, что скажем Smarty наплевать на валидность/инвалидность значит он может заменитьЯ хочу сказать, что если ты используешь XML/XSLT ты должен обеспечить валидный XML источник, а в случае с шаблонизаторами вроде <?=$some?> я могу позволить себе писать такой HTML какой хочу. Хочу забуду закрыть <li>, хочу слеш не поставлю в img и т.д.
то этот текст по определению является контентом и значит по определению не должен включать элементы оформленияПочему же. В содержимом мы задаём логику документа => если тот же клиент имеет возможность вводить содержимое, то он и логику может задавать.
все тэги оформления и другие от которых может "поехать" дизайн всего сайта вырезаютсяТ.е. если клиент написал в коде <img ...> то я должен его вырезать? А кому такой CSM нужен будет тогда...

[denver]

RaZEr
Я хочу сказать, что если ты используешь XML/XSLT ты должен обеспечить валидный XML источник, а в случае с шаблонизаторами вроде <?=$some?> я могу позволить себе писать такой HTML какой хочу.
Снова тебе RaZEr повторю, ты не обижайся, в XML ты можешь себе позволить любой HTML код какой захочешь!!1

Т.е. если клиент написал в коде <img ...> то я должен его вырезать?Приехали. Нашел к чему придраться...
Хочешь вырезай а хочешь оставляй, дело то твое.

y13
Маше, Васе и потребителю до лампочки, что там использовал Петя
Это глупый менеджер так поначалу всегда думает, ага... И точно точно, гляди, вот так же подчеркивает эти слова! :claps:
А потом:
Никакой шаблон недолжен нести код. Мы помним, что этот самый шаблон рисовала Маша, а она ни php, ни perl даже в глаза не виделаЭто он потом уже типа думает, ага... А может вообще не подумать, а Маша и Петя будут его вспоминать нехорошими словами, пока не сдадут проект.

Нет, брат y13, хреновый из тебя проектировщик и менеджер :biggrin:

[RaZEr]

Снова тебе RaZEr повторю, ты не обижайся, в XML ты можешь себе позволить любой HTML код какой захочешь!!Да не любой, далеко не любой. Ты думаешь я парсер эрроров мало видел?! Понимаешь все XML/XSLT парсеры хотят 100% валидный HTML т.е. - XHTML. А это проблема. И коды счетчиков и различные блоки страниц, которые клиенты хотят редактировать сами. И дубль два - они хотят редактировать не результирующий HTML, а исходное содержимое которое потом пройдет через парсер!

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

[denver]

RaZEr
Может ты приведешь пример? А то я что-то не могу понять что за сайты такие проблемные ты там разрабатываешь.. Пример в студию.

[RaZEr]

Да просто всё. Есть CSM, есть визуал-редактор (window.design_mode). Последний из них имеет привычку генерировать не слишком валидный код (IE вариант), который тем не менее неплохо бы пропустить через XSLT. Хотя бы потому что простой тег <p> может быть в дизайне представлен красивым блоком с округлыми краями.

[y13]

RaZEr

Снова тебе RaZEr повторю, ты не обижайся, в XML ты можешь себе позволить любой HTML код какой захочешь!!1

Приехали. Нашел к чему придраться...
Хочешь вырезай а хочешь оставляй, дело то твое.

y13

Это глупый менеджер так поначалу всегда думает, ага... И точно точно, гляди, вот так же подчеркивает эти слова! :claps:
А потом:
Это он потом уже типа думает, ага... А может вообще не подумать, а Маша и Петя будут его вспоминать нехорошими словами, пока не сдадут проект.

Нет, брат y13, хреновый из тебя проектировщик и менеджер :biggrin:

А теперь, если можно, по-русски и со смыслом. С доводами, с примерами, и чётким обоснованием собственной мысли. А то так, фикция сплошная.

P.S.
Глупый, не глупый, а деньги получает. Маша с Петей не грустят. Проекты вовремя уходят. Странно да? Надеюсь, без глупых намёков и поспешных выводов Вы сможете прожить? Иначе я тоже наделаю поспешных выводов и ретируюсь задом. Не вижу смысла спорить если у оппонента такой взгляд на мир. Ничего нового так и не узнаешь.

[denver]

y13
Свои мысли я расписал на предыдущей странице и мне нечего добавить. Ежели ты хотел лишь сказать что использовать темплейты вообще это лучше чем их не использовать, то ты открыл америку, по-моему никто иначе и не считает :cool:

RaZEr
На твоем бы месте, весь код от этой HTMLArea на выходе обрабатывал бы автовалидатором (автоматом закрываем все тэги). Если ты считаешь что это тупо то что поделать -- ты хочешь и на... сесть и рыбку съесть :)
Я бы не стал думать об обработке пользовательского текста XSLем. Это слишком чревато, да и не нужно никому.
простой тег <p> может быть в дизайне представлен красивым блоком с округлыми краями
Я не видел ни одного сайта где такое реализовано, и вряд ли будет до выхода CSS3 (а в мозилле уже есть вон -moz-border-radius межпрочим, говно, а и то хорошо)

y13
А теперь, если можно, по-русски и со смыслом. С доводами, с примерами, и чётким обоснованием собственной мысли
Если я еще четче, еще понятнее, еще доходчивее, еще подробнее напишу чем я распинался страницей ранее, то меня поймет любой имбецил. Но я не люблю разъяснять имбецилам.

[Hubbitus]

denver:
Так ты все же сначала разберись что ты хочешь-то дайте мне идеальную систему темплейтов и конечно быструю, и простенькую чтобы... FastTemplate!
Именно этим я и занимаюсь - разбираюсь что же собственно требуется от шаблонов в общем случае, какие задачи и пути их решения. Как я уже говорил выше, я уже написал класс, типа этого FastTemplate, где реализовал основную функциональность необходимую мне на данный момент и постоянно помаленьку дописываю при возникновении новых задач... Как я всевремя подчеркиваю, меня интересуют больше основы и принципы реализации, а не сама реализация, а мне постоянно пихают куски кода, как-будто я просил написать мне на PHP строку замены переменных в тексте или что-то подобное!!!!denver:
XSLT всем хорош. Но зачем упоминать все его достоинства если в рамках данного топика это оффтопик. Я думаю что и Smarty при желании можно делать то-же самое, только это никому особо не нужная функциональность.
Может все и не нужно, а основные какраз необходимо. В Смарти можно делать многое, но я же привел где-то выше пример что из него получается в таком случае... подозреваю на XSLT ничуть не понятнее (для дизайнера) и не проще получится код при написании нетривиального оформления...
Вот, и RaZEr очень прав сформулировав так задачу обсуждаемую здесь:RaZEr:
основной предмет разговора - полное и грамотное разделение оформления и содержания.
не больше не меньше, пока мы даже не пришли ни к какой конкретной ("грамотной" или идеальной, если хотите) концепции разделения!!

y13:
Оформление от Маши, движок от Пети, а содержимое от клиента (он же – конечный потребитель созданного блага). Вот это – полное и грамотное разделение оформления и содержания. Маше, Васе и потребителю до лампочки, что там использовал Петя: FastTemplate, Smarty, XML, HTML::Template или ещё какую технологию. Это заботы конкретно Пети.
Ага, а если исполнитель и дизайна и программирования логики и координирования проекта это один человек, то и говорить нечего :) Ты подумай банально, он реализовал на одном, подключили еще программиста (или просто подумай что потом кто-то править будет) - и он вынужден разбираться что наворотил Петя... Но это даже врядли главное, первый вопрос посути - как ему-то что-то выбрать и по каким критериям из доступных технологий?

y13:
Никакой шаблон недолжен нести код. Мы помним, что этот самый шаблон рисовала Маша, а она ни php, ни perl даже в глаза не видела - У неё есть 8Mpx цифра, яблочный комбайн, ручки и хорошие способности к рисованию. А вот Петя, уже должен суметь без запускания пальцев в исходный макет (идеальный вариант) написать систему, которая этот конкретный макет будет использовать.
Вооот, вот об этом я и говорил - дизайнер должен дизайнить (уж простите за каламбур). Ну и если ему сказать что на странице вместо "Вася" нужно писать скажем "{NAME}" то он это еще должен пережить, а если ему скажут что он должен написать еще и логику отображения, на какаом-либо языке (будь то XSLT или Smarty или другие) то это уже странное какое-то разделение. С другой стороны, если все это возложить на программиста, которому дают картинку лишь дизайна на входе (как я понимаю так чаще всего и бывает), то ему вообще проще расставить в HTML вставки типа <?=$var?> поместить это в БД, ну или в файлах сохранить и просто выводить в нужных местах - ничего быстрее этого не придумаешь уж точно - ноль обработки.denver:
На твоем бы месте, весь код от этой HTMLArea на выходе обрабатывал бы автовалидатором (автоматом закрываем все тэги). Если ты считаешь что это тупо то что поделать -- ты хочешь и на... сесть и рыбку съесть
Кстати незнаю как для тебя denver, но это крайне актуально на самом деле, ты видел какой код формируется в таком WYSIWYG редакторе? Там помоему сам Гейтс не сможет часто объяснить как это так вдруг так получается! А еще нужно учесть подобные прибпмбпсы для разных браузеров...

[denver]

Hubbitus
Да, я видел что получается из HTMLArea особенно если в нее копипэйстить мсворд. Однако все проблемы не так актуальны если юзать:
$allowed_tags='<a><br><b><h1><h2><h3><h4><i>' .
'<img><li><ol><p><strong><table>' .
'<tr><td><th><u><ul>';
$userhtml = strip_tags($_POST['userhtml'], $allowed_tags);

Именно этим я и занимаюсь - разбираюсь что же собственно требуется от шаблонов в общем случае
В общем случае требуется:denver:
1. Отделение PHP кода от HTML кода.
либо
2. Отделение бизнес логики от логики отображения.
Т.е. общих случаев два. Второй это как раз то что тебе не нравится -- верстальщик занимающийся "программированием" вывода. Значит для тебя только FastTemplate. Гыыыыыыы :yees:

[RaZEr]

Однако все проблемы не так актуальны если юзатьimg элемент IE не закрывает. Тоже убрать? А как быть с font? И его убрать? Может сразу перейти на VbCode :cool: ...

[denver]

Hubbitus
Да, еще отвечая на все твои вопросы об экстракоде Smarty и концепции разделения,
это ли уже будет в итоге не программированеи вывода, только верстальщиком????
Да, это будет программированием вывода. Но зато мы разделяем программирование вывода от программирования сайта. Важно в данном случае не то что в коде (сайта) не будет задаваться переменная цвета (конечно значение можно прописать в шаблоне), важно то что переменных цвета вообще (!) не будет и т.п. Именно это дает полную независимость бизнес логики от оформления.
Нагляднее всего выгода от этого прослеживается когда меняется дизайн сайта и вместо меню скажем в одну колонку меню становится в две колонки (в первом четные, во второй нечетные), программер PHP отдыхает. Однако главное не то что он отдыхает, главное то что если на движке этого сайта работают еще два сайта (скажем клоны, расчитаны на другие ниши) то в их PHP коде ничего не поменяется, потому что так и должно быть -- офорление вторично. Следующая "версия" сайта подойдет под все эти сайты с минимумом правок PHP (или вовсе без них).

RaZEr
Зачем существует VbCode мне непонятно. Скорее кто-то (тоже очень мудрый) подумал что HTML разметка очень сложная -- давайте заменим ее на "попроще". На мой взгляд VbCode только усложняет жизнь, выучить пару тэгов HTML не составляет труда и полезней чем помнить VbCode.

Имиджи можно закрывать автоматом, можно не закрывать, еще еще еще еще еще раз плюну в тебя функцией htmlspecialchars() которая спасет тебя от любого невалидного HTML внутри XML.

А как быть с font? И его убрать?
Какая-то странная у тебя тактика меня достать... Оставляй <font> если нужно или вырезай <font> если не требуется :idontnow:

[RaZEr]

Зачем существует VbCode мне непонятно. Скорее кто-то (тоже очень мудрый) подумал что HTML разметка очень сложная -- давайте заменим ее на "попроще". На мой взгляд VbCode только усложняет жизнь, выучить пару тэгов HTML не составляет труда и полезней чем помнить VbCodeМне VbCode нравиться тем, что теги пишутся без шифта :) А так конечно HTML был бы проще. Но разработчики рассудили верно - зачем зависеть от надежности striptags(), когда можно написать свой мини-парсер, который по крайней мере с родными багами :)

плюну в тебя функцией htmlspecialchars() которая спасет тебя от любого невалидного HTML внутри XMLДесять раз я сказал что нужна разметка, а не текст и десять раз ты мне предложил превратить её в текст :)

Какая-то странная у тебя тактика меня достать... Оставляй <font> если нужно или вырезай <font> если не требуетсяЭто лишь пример (я имел ввиду тот факт, что тег font устарел). Там много примеров ... те же кавычки которые то одинарные, то вообще отсутствуют. И & он на &amp; никогда не заменяет. И ещё там масса примеров.

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

[denver]

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

[RaZEr]

Я вообще ничего не хочу решить :) Со своими подходами к этому вопросу я давно определился.

Я просто говорю тебе о том, что XML более зависим от своей "валидности" нежели какой-нибудь самопальный темплейтер "раз и готово". Вот есть например ламерский парсер заменяющий {имя_переменной} на значение. Он рулится обычными регами и в самом страшном случае просто заменит тег на пустую строку или же оставит нетронутым (если тот не попал под регу). XML же куда более капризен. Упаси меня не закрыть какой-нибудь тег или оставить невалидный символ, - сразу парсер эррор и всё сорвано.

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

[denver]

RaZEr
В каком случае тебе не подойдет текст, о котором ты говоришь тут:
Десять раз я сказал что нужна разметка, а не текст и десять раз ты мне предложил превратить её в текст
(исключая случай когда надо в клиентском (неизвестно валидном или нет) коде <p>...</p> заменять на <div class="roundcorner"><div class="top">...<div class="bottom"></div> и т.п. -- таким не занимается ни одна система темплейтов мне известная).

[RaZEr]

Помнишь с чего я начал?Вы не забывайте, что XML будет посложнее в реализацииИменно это я и хотел донести.

[denver]

RaZEr
Я уж кажись привел пример. Не шибко сложный был, да :)

[RaZEr]

Да. Только явно не в кассу. Практика показывает, что пока с внедрением XML немало проблем. Это не моё мнение, это - факт.

[Hubbitus]

denver:
Назначение топика насколько я понял -- рассмотреть разные системы темплейтов, сравнить их, выбрать опимальную и т.д. а ты же хочешь решить те проблемы которые ни одна из них не решает: человеческий фактор.
Нееееет, не стоит такого назначения выбрать оптимальную систему из существующих, видимо ты совсем так ничего и не понял, а споришь!!! Стоит вопрос сугубо теоретический, как делать лучше, как отделять, на каком принципе и т.д. Гдя я написал что мне нужно что-то готовое, или рассмотреть нужно из существующих, или я хочу выбрать какой-то готовый инструмент? И RaZEr крайне прав, приводя недостатки того или иного. Тебе я тоже очень благодарен за первый твой пост, где ты корректно и полно описал преимущества того что тебе нравится использовать... только не нужно зацикливаться, и критикуя этот подход мы (я покрайней мере), не тебя критикую, как его пользующего, а именно стараюсь выделить недостатки и изъяны...
RaZEr:
Со своими подходами к этому вопросу я давно определился.

Можно поподробнее в чем он состоит, этот подход? Я чего-то все меньше понимаю в этом вопросе, как мне кажется :beer: RaZEr:
Да. Только явно не в кассу. Практика показывает, что пока с внедрением XML немало проблем. Это не моё мнение, это - факт.
Это факт, который обсуждается где только не лень, почти на каждом форуме подобной тематики, и я уже приводил пару наиболее авторитетных линков...

[denver]

RaZEr
Пока что ни одной неразрешимой проблемы я не услышал. Это тоже факт :cool:

[RaZEr]

Пока что ни одной неразрешимой проблемыНеразрешимых проблем нет. Есть стоимость и сроки решения проблем, и на сегодня они не всегда в пользу XML.

[denver]

RaZEr
Очень умно. Но я не вижу ни одной проблемы которая была бы столь сложной что заняла бы больше времени чем какая-нибудь рядовая задача ;)

[RaZEr]

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

[denver]

RaZEr
Это уже другой вопрос. Собственно это я и хотел услышать.

[RaZEr]

Ну слава богу. Не подрались - уже хорошо ;)

А по существу. Есть идеи как грамотно превратить невалидный XML в максимально валидный?

[denver]

RaZEr
Чтоб ты не подумал ничего хорошего я имел ввиду что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написано ;)

Максимально валидного XML не бывает (бывает валидный или нет). XML по сути не предназначен для правки человеком (хотя и не исключает этого). XML должен создавать программист (через скрипт) а не пользователь. Если прораммист граммотный то XML будет валиден всегда, даже если содержит текст пользователя. Если текст пользователя содержит HTML то его можно автоматом приводить к XHTML либо пропускать через htmlspecialchars(). Я еще не видел написанной кем-то реализации HTML->XHTML, наверное от htmlspecialchars() никто пока не страдал.

[RaZEr]

что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написаноА как же вы, любезный, поступаете, когда не повезло с хостингом? "Качество не моей мануфактуры"?...
Максимально валидного XML не бываетmaximum = as much as possible = как можно более.
XML по сути не предназначен для правки человекомЦитата с W3C будет?
наверное от htmlspecialchars() никто пока не страдалТы уже дал ответ на этот вопрос:это соответсвует натуре человека -- чем разобраться...

[Sheryld]

как это я не заметил такую интересную дискуссию?:)

про валидный xml:

есть xml-схема, есть DTD, есть прочее, т.е. проблем с проверкой нету, есть проблема с составлением правил(что обрезать, а что нет).

про xslt:

предлагается следующее упражнение(типичная задача для вывода каталога):

1. есть некоторый xml-файл с данными(там только данные, как и предложил denver). что-то типа:

<catalog>
<item>
<id>1</id>
<title>АААААААА</title>
</item>
<item>
<id>2</id>
<title>БББББББББ</title>
</item>
<item>
<id>3</id>
<title>ВВВВВВВВв</title>
</item>
<item>
<id>4</id>
<title>ГГГГГГГ</title>
</item>
</catalog>
....

2. есть некоторый шаблон(xslt).

3. есть код на php, который выдает html(ну то есть типа: $xsltInstObj->out("my.xml","my.xsl");)

внимание задача:):

вывести все данные в n-столбцов, отсортированные свверху вниз, т.е. типа:

а г ж й
б д з
в е и

за n возьмем - 4(столбца)

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

если еще усложнить задачку, то вывод должен быть таким:

<table>
<tr>
<td>
1 элемент 1 столбца
</td>
<td>
1 элемент 2 столбца
</td>
<td>
1 элемент 3 столбца
</td>
<td>
1 элемент 4 столбца
</td>
</tr>
</table>

по идее в подходе Денвера, это логика вывода, которая ложится на верстальщика. Завтра все приходим на работу и даем задание верстальщикам, о результатах пишем здесь:)

[denver]

Sheryld
Ну формулой будет ceil(count($items)/$n)) тут долго думать не надо. Особенность реализации зависит от конкретного языка будь то Smarty или XSLT, скорость реализации зависит от знаний/опыта верстальщика в этом языке.

Да, XSLT это в язык прораммирования (только вывода). Однако смешно смотреть на сборище снобов пэхапэшников которые так наивно уверены что верстальщик не может (не в состянии, не хватит мозгов, куда там) выучить язык программирования, что это только пэхапэшнику дано, но пэхапэшнику скучно его учить. Почему бы не рассматривать это и так: "нам нужен программер PHP(соотв. +MySQL,+Unix, etc) и программер XSLT(соотв. +HTML, +CSS etc)"? "Программер" XSLT будет ненамного дороже верстальщика HTML, однако в результате это будет настоящее отделение контента от оформления.

RaZEr
В спецификации PHP тоже не написано что код не предназначен для правки пользователем, тем не менее, ты обычно не советуешь заказчику менять даже константы в коде.
Аналогично хочется спросить -- "максимально валидный XML" -- цитата с W3C будет?

From RaZEr: Денвер! Личку - в ПС. Демогогию эту устраивай в другом месте!

[Sheryld]

дьявол кроется в деталях.

покажи реализацию на xslt.

[denver]

Sheryld
Ну скажем вот решение для n=4:
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<head>
<title>Four columns layout</title>
</head>
<body>

<xsl:variable name="maxperrow" select="ceiling(count(//item) div 4)"/>
<xsl:variable name="col" select="//item[position() &lt;= $maxperrow]"/>

<table border="1" cellpadding="5">
<xsl:for-each select="$col">
<xsl:variable name="current" select="position()"/>
<tr>
<td><xsl:value-of select="//item[$current+$maxperrow*0]/title"/></td>
<td><xsl:value-of select="//item[$current+$maxperrow*1]/title"/></td>
<td><xsl:value-of select="//item[$current+$maxperrow*2]/title"/></td>
<td><xsl:value-of select="//item[$current+$maxperrow*3]/title"/></td>
</tr>
</xsl:for-each>
</table>

</body>
</html>Может шокировать конечно количество XSL кода (можно было бы обойтись без переменных, но так нагляднее и удобнее), на практике HTML намного больше конечно. В любом случае не вижу особенных слжностей, на Smarty решение было бы похожим.

[Sheryld]

не знаю как вам, мне определенно понравилось.

[Hubbitus]

denver:
Да, XSLT это в язык прораммирования (только вывода). Однако смешно смотреть на сборище снобов пэхапэшников которые так наивно уверены что верстальщик не может (не в состянии, не хватит мозгов, куда там) выучить язык программирования, что это только пэхапэшнику дано, но пэхапэшнику скучно его учить.
Ну а отсюда снова начальный вопрос, почему верстальщику тогда не выучить несколько конструкций PHP, раз все согласились что решение будет равносильно, а именно нужно XSLT? Про дешевле и т.д. не будем разводить нюни... А если это программирование вывода будет на PHP и отдельно от программирования бизнес-логики, то помоему это вполне подходит под твое 2 разделение, не так ли?

denver:
Чтоб ты не подумал ничего хорошего я имел ввиду что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написано
Интересно, а разбираться в уже написанном (тотже Смарти) или темболее написать что-то свое это лень разбираться с XML и XSL??? Странная логика однако, вот ведь лентяи блин, эти создатели Smarty!...

[RaZEr]

Аналогично хочется спросить -- "максимально валидный XML" -- цитата с W3C будет?Причем же здесь W3C. Это не утверждение, а формулировка. Вполне понятная. Необходимо (было) добиться максимально возможного приближения HTML к XHTML. Но да ладно, - вопрос снят. От греха подальше, как говориться :beer:

Ну а отсюда снова начальный вопрос, почему верстальщику тогда не выучить несколько конструкций PHP, раз все согласились что решение будет равносильно, а именно нужно XSLTЕсли у нас есть: А - набор информации выданной скриптом, Б - шаблон определяющий порядок и количество информации, В - стиль оформления задающий внешний вид. То мы можем создать XHTML при помощи PHP, а затем его оформить XSLT стилем. Тогда все останутся довольны :beer:

[denver]

Hubbitus
PHP в качестве языка логики оформления :rolleyes: Ну это ты вернешься к тому с чего начал: <?=$color?> и т.п., тоже неплохо собственно ;)
А если серьезно, то просто возникнет вопрос безопасности, PHP в этом плане шибко мощный.

RaZEr
мы можем создать XHTML при помощи PHP, а затем его оформить XSLT стилем
Эээ.. тоже конечно можно. Однако это получится что из одного шаблона мы делаем другой шаблон, а потом уже HTML.

ЗЫ. :beer:

[Sheryld]

тут есть одно фундаментальное преймущество.

xslt реализован на множестве платформ, как следствие имеет большую популярность, документированность и т.д.

я вобщем об этом писал, немного выше:


А если это программирование вывода будет на PHP и отдельно от программирования бизнес-логики, то помоему это вполне подходит под твое 2 разделение...


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

[RaZEr]

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

[Sheryld]

я не о php в целом, а о smarty в частности.

если все делать по-человечески, то вся логика отображения и верстка перейдут из php — куда угодно, практически без правок. меняем только бизнес логику и парсер.

пример: переезд сайта с php на asp.net.

[RaZEr]

Пример плохой (не часто такие переезды происходят), но я с тобой согласен - из связки FastTemplate, Smatry, XSLT последний будет предпочтительнее.

[Hubbitus]

denver:
А если серьезно, то просто возникнет вопрос безопасности, PHP в этом плане шибко мощный.
Гы, "слишком" хорошего или мощьного не бывает, также как не бывает слишком много денег :p :beer:

[denver]

Hubbitus
В плане небезопасности мощный.
Ладна, завязываю тута :end:

[denver]

Hubbitus:
Опять же очень актуальные проблемы с парсингом xhtml в Експлорере (http://xpoint.ru/forums/thread/25797.xhtml)Я тут тоже провел аналогичный эксперимент... Результаты необнадеживающие.
Попробуйте сами промотреть приведенный ниже HTML в любом браузере.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<style>
body {
color: black;
}
div {
color: red;
width: 100px;
height: auto;
border: 10px solid;
}
</style>
</head>
<body>
<h1>Header with body as parent</h1>
<div />
<h1>Header that also seems to have body as parent
(according to the W3C specification)</h1>
</body>
</html>Опробовано на IE 6.0, Mozilla Firefox 1.0, Opera 7.51. Печально что даже Mozilla, считающийся надеждой W3C, успешно провалил данный пустяковый тест...

NB. Можно менять DOCTYPE на любой или вообще его убрать, похоже в данном случае он ни на что не влияет.

[ftpd]

Konqueror из КДЕ 3.4 отобразил правильно....
т.е. черным цветом оба

[Hubbitus]

denver:
Опробовано на IE 6.0, Mozilla Firefox 1.0, Opera 7.51. Печально что даже Mozilla, считающийся надеждой W3C, успешно провалил данный пустяковый тест...
Дак о чем это говорит-то? Не о том ли о чем я говорил - что проблем с XHTML еще предостаточно...

Кстати, http://feofanov.fizteh.ru/anal/xsltbug.html вот тут еще наткнулся на критику XML + XSLT, помоему весьма аргументировано. И тут не все гладко... :(

[RaZEr]

Надо отдать должное автору, - аргументация и вправду понятная и убедительная. Хороший пример нам всем :cool:

[denver]

Hubbitus
На месте его клиентов я бы тоже голосовал рублем в пользу другой компании. Из-за вот таких вот решений:
Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей архитектуры), потом XML данные загружаются в...
Тут налицо явная некомпетенция этого "директора", которого ввели в заблуждение горе специалисты. Так как описано делать действительно глупо и нерационально.

ЗЫ. Все остальное уже дососано из пальца (XSLT это сложно, XSLT это не так мощно, XSLT это опять сложно... и т.п.)

[RaZEr]

Тут налицо явная некомпетенция этого "директора", которого ввели в заблуждение горе специалисты.Денвер, обосрать можно кого угодно. Говори по делу. "Вот так неправльно, правильно так-то"...

[denver]

RaZEr
Вот так неправильно: при каждом запросе перегонять все (!) данные из MSSQL в XML чтобы потом XSLT сделал выборку. Это так же неправильно как делать SELECT * FROM table; чтобы потом этот массив обрабатывал ASP или PHP или еще там что. А то что они именно так и делали говорят фразы типа:
...далее XSLT проходит по огромному массиву данных... Потребность в масштабирование таких проектов возникает уже начиная с 1000-10000 уникальных пользователей в день...
Неудивительно что масштабируемые, если постараться можно и непродуманными SQL запросами увеличить "масштабируемость" MySQL, MSSQL и т.п.

[RaZEr]

Что они так НЕ делали, - очевидно. При простой выборке новостей, статей, тем форума и т.д., получим десятки тысяч записей БД (SELECT * FROM table;). Памяти для такой XML структуры не хватит и для одного пользователя на весь сервер.

Тут имелось ввиду то, что при обработке XSLT мы вынуждены грузить в пямять два "текстовых файла" (*.xml и *.xsl) что жрёт довольно много памяти.

[denver]

RaZEr
два "текстовых файла" (*.xml и *.xsl) что жрёт довольно много памятиНу и что за сарказм заключается в кавычках? Или без сарказма? Тогда фраза вызывает сомнения... ну скажем есть 10 Кб XML и XSL 10Kb, "довольно много" это 20Кб?

...далее XSLT проходит по огромному массиву данных...
Вот "огромный" тут я подозреваю совсем не 10 Кб. Поэтому и сделал вывод что кое-чего в XML они пихали действительно лишнего...

[RaZEr]

В кавычках цитата. Памяти XSLT-обработка жрёт нестолько "много" сколько "больше чем".

[Hubbitus]

denver:
Ну и что за сарказм заключается в кавычках? Или без сарказма? Тогда фраза вызывает сомнения... ну скажем есть 10 Кб XML и XSL 10Kb, "довольно много" это 20Кб?
Вобщем пришлось мне столкнуться с парсингом XML на PHP и результат вполне ожидаем - XML-файл порядка 2МБ, при выборке и обработке его потребовал больше 10 метров оперативки!!! Ну да, у меня на серваке гиг стоит, но всеравно при таких объемах (и это без XSLT и прочего всего, просто из него выбирались элементы, получались данные) сколько пользователей одновреименно можно будет обслужить??? Ответ в любом случае (предвижу оптимистичную критику denver'а) весьма удручающий...
RaZEr:
Что они так НЕ делали, - очевидно.
Тут я тоже полностью согласен - НЕ так!
denver, ты сам подумай, это какой бы у них должен был бы быть мэйнфрейм на каждый магазин, чтобы перегонять базу всю в XML ("Самые большие каталоги вмещали по 70000 товаров.") да еще потом и обрабатывать, при посещаемости от 1000 человек!!! Это терабайты оперативы и сотни процов!! Так что это просто исключено - там делались нормальные выборки.

[denver]

Hubbitus
Так что это просто исключено - там делались нормальные выборки.
Как думаешь, сколько занимает итоговый XML при "нормальной" выборке?

[RaZEr]

сколько занимает итоговый XML при "нормальной" выборкеДаже при выжимке самых необходимых данных XML занимает довольно много. Вот простой пример:<product>451</product>Итого данных - 3 байта, оформление - 19 байт. Это хорошо расходует память. А там ещё XSL где почти всегда есть неиспользуемые xsl:template блоки ... хорошо вообщем получается. Не смертельно. Но тем не менее.

[denver]

RaZEr
Не смешите меня. И вообще, я хотел услышать размер *итогового* XML, по вашему мнению.

[RaZEr]

Вот взял базу мп3 ... 10МБ ... 80К записей => ~125 байт на каждую. Скажем выводим по 20 на странице. 125*20 = 2.5К что у нас там ... id,title,artist,album,kbps,time,size + оформление 30*2+3*7=621. *20 = 12420. Итого ... на одном XML мы получили вместо 2.5 - 15 (2.5+12.5) т.е. в разы увеличили расход памяти. Для хорошо посещаемых проектов (100К хитов и больше) учитывать это немаловажно.

[denver]

Ок, все правильно. Однако я не вижу "огромного массива данных" как в случае с "нормальными выборками" от той компании.
...далее XSLT проходит по огромному массиву данных...
Что в принципе и правильно. Никаких действительно огромных массивов не должно быть, выводим лишь то что в последствие будем использовать.

А наезды на тэги, которые занимают лишнее место, конечно обоснованы. Но это наезды на идею всего XML. Может вы противники XML как такового? :biggrin:
Хочешь "машинно+человеко-ориентированно" -- выводи/храни в XML, хочешь оптимизированно и понятно только машинам -- храни в своем формате. XML+XSLT это прежде всего для программеров и верстальщиков (для человеков), а потом уже для машины. Не нужна абстракция используй FastTemplates или вставки <?=$foo?>.

[RaZEr]

Может вы противники XML как такового?Боже упаси ;)

XML+XSLT это прежде всего для программеров и верстальщиков (для человеков), а потом уже для машиныТы не так давно говорил что XML прежде всего для машины, а не для человека. Противоречишь себе. Но в данном случае я с тобой согласен - размер возрастает из-за удобочитаемости, которая необходима т.к. XSL создаёт человек.

[denver]

RaZEr
Если я так и говорил то я неверно сформулировал :) Конечно XML в равной степени (не)удобен и тем и другим.

Вот еще одно необдуманное утверждение из статьи:
Полная смена дизайна требует полного переписывания всех шаблонов, что в расчете на сложность создания XSLT получается еще дороже.
В рядовых случаях полная смена дизайна (именно его, т.е. оформления данных) требует полного переписывания лишь HTML. Не обязательно знать XSLT чтобы найти и изменить HTML блоки в нем. Когда же встает вопрос об полном изменении XSLT тогда (при граммотном PHP) очень редко встает вопрос об изменении еще и PHP. Но если не XSLT задает логику отображения (допустим мы используем FastTemplate), тогда это делает PHP. И это еще вопрос -- кто из спецов дороже -- (программер PHP + верстальщик HTML) или только (верстальщик XSLT+HTML).

[RaZEr]

Высказывание в высшей степени необдуманное. Не обратил на него внимание. XSLT в моём понимании это то, что позволило наконец полносью абстрагировать оформление. Т.е. решить задачу с которой так и не справился CSS. Поэтому смена дизайна XSLT сайта на порядок проще аналогов. Конечно при условии что разработчики понимали что делали ;)

[Sych]

Вот перечитал на досуге топик - развели тут святую войну аж жуть...

Большинство фраз которые тут прозвучали - надуманные и получаются из за непонимания web технологий и концепций построения приложений в целом.

Хотя Я сам являюсь ярым приверженцем рационального использования xml+xslt, Я никого не заставляю пользоваться этими мощными инструментамим - на все свое время.

Кому-то и plain html сейчас до сих пор подходит.

Вышеприведенная статья имхо "умная" но бездарная...

З.Ы. xml+xslt это ведь не только быстрая смена дизайна, версии для печати, wap версии, pdf и тд.

[RaZEr]

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

[Sych]

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

Писать тонну информации о том какие сложные шаблоны xslt, про большие и маленькие иксэмэли и другие надуманные проблемы (ведь 90% этих проблем просто надуманно), как неправильно работает xhtml в браузерах и тд. То же не вижу смысла.

Основная проблема использования этой связки это низкий уровень подготовки персонала так как сразу с php или чего то друго го не перескочишь, потому что надо за один раз разобраться аж в 3 вещах как минимум (DOM, XML,XSLT,XPATH итд.)

По этому для некотрых эта связка является обычным рабочим инструментом, а для других чем то божественным на которое надо молится.

[denver]

Sych
Типа "пробегал я мимо, спорите о чепухе, я бы тоже поспорил да не о чем, вы все лохи а я дартаньян, учите матчасть" :yees:

[Sych]

У каждого разный взгляд на одну и ту же проблему. И если некоторые себя тут считают "не сильно компетентными" в вопросе по данной теме то это уже личное дело каждого.

Можете бросить в меня камень за этот простейший пример (http://www.php.com.ua/download/xml_template.zip/) который как мне кажется наглядно демонстрирует приемущества работы такой связки. см.так же пост 42 в этом топике

Для людей которые особо не верят в магию - напомню что XSLT это офф. стандарт W3C - который по моему мнению у разработчиков должен быть по приоритетам на 1 месте.

[Sheryld]

Кстати про память. Считать нужно не так. Считать нужно исходя из того, сколько занимает в памяти все дерево xml(при использованиии DOM), а это напомню:

экземпляры классов;
методы;
поля;
метаданные и т.д. и т.п.

[denver]

Sheryld
Я согласен с тем что в памяти должно храниться дерево элементов, так назыв. Document Object Model.
Поля и метаданные -- еще можно отнести к DOM, но о каких экземплярах класса и методах идет речь? Где такой RTFM брали? :confused:

[Sheryld]

Ну а как же. Создается когда экземпляр класса(например, DomDocument) он же требует выделения памяти? Насколько я себе представляю php. Он написан на с++. Поэтому там действуют те же самые законы, при этом работает интерпретатор и парсер(которые и обеспечивают поддержку данного синтаксиса).

Кстати, интересно, а можно ли напрямую вызвать функцию(экспортируемую) из бибилиотеки, если писать программу на с++?:)

[denver]

Sheryld
Насколько мне известно в XML нет ни методов, ни функций, ни класов, ни их экземпляров :-/
Ну а как же. Создается когда экземпляр класса(например, DomDocument) он же требует выделения памяти?
Ничего не понятно, когда создается?

---8<-------8<-------8<----
...Вырезано так как чушь :)
---8<-------8<-------8<----