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

[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 строчку каждого файла шаблонов трогать нельзя

Ale:
б) вы увеличиваете объем кода на треть, соотв увеличиваете стат вероятность

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

Остальные доводы трогать не буду, т.к. с объективными-то показателями не все в порядке...
Кстати совсем не понял аналогии с DOS/WIN, Perl/PHP....

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.

PHP код:

<? include ('main.php');
ob_start("replace"); ?>
<html>
<head>
<title>{TITLE}</title>
</head>
<body bgcolor={BGCOLOR}>
{CONTENT}
</body>
</html>
<? ob_end_flush(); ?>

содержание main.php

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.

PHP код:

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

содержание main.php

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) и позволить пользователям делать максимум на остальном уровне, при этом чтоб уменьшить вероятность взлома.

Тоесть все остальное не важно, производительность например? Хотя наконец-то кто-то обозначил более или менее цель этого всего.

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

В готовом проекте можно просто отключить вывод сообщений об ошибках и в этом примере во втором варианте мы получим просто <title></title> а в первом еще и выведем информацию которая может помочь злоумышленникам во взломе, это уж если говорить о безопасности.

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

Ну если излишнее создание переменных минус, то можно сделать один массив... А вот о целесообразности создания нового Markup Language я и поднял вопрос, и на протяжении всего этого топика его пытаемся со всеми решить!!!
plohich я так и не понял твоего мнения по этому поводу, как делать "правильнее" и почему? Сравнивая эти варианты, к чему ты пришел, какой лучше (или может третий какой-то)?

[plohich]

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

[dacuan]

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

склоняюсь больше к первому варианту. закодированное ядро, а для пользователя создается свой 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 - тоже убийственно, поэтому это не может заменить БД в любом случае.
Мне кажется что третье наиболее существенное препятствие.