Форум PHP

>>но это обращение к файловой системе при каждой интерации цикла.
если файл один и тотже, при каждой ли?
upd
к тому же, если цикл перенести в шаблон, инклуд будет только один раз.

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

>>
>В вашем подходе да, но вы фактически даёте лишь доступ к переменным, но не методам их обработки (методы PHP означают необходимость в знании хотя-бы основ PHP).

А нафига верстальщику способы обработки? Это его забота? Наобрабатывал уже один так, что вообще всё работать перестало...

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

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

<?     function parseTpl($cont, $data)     {         extract($data);                       ob_start();             eval('?>'. $cont .'<?php');             $code = ob_get_contents();               ob_end_clean();                      return $code;     } $rows = ''; $cont = file_get_contents('rows.html'); $q = mysql_query($sql);  while($r = mysql_fetch_assoc($q)) { $rows .= parseTpl($cont, $r) }

template.html

<table> <?php echo $rows; ?> </table>

rows.html

<tr>     <td><?php echo $field ?></td> </tr>

Для меня преимущества очевидны -
1. отсутствие суррогатного синтаксиса
2. минимальный дополнительный функционал (функция используется только в необходимых местах, циклах и пр)
3. простор для маневра. Можно свободно использовать и чистый натив, как у Вас в примере.
4. Шаблон верстается без оглядки на интерфейсы, простым и чистым HTML, который потом делится на состовляющие. Кроме того, вывод переменных в дескрипторах не вредит верстке, так как браузер их просто игнорирует.
Из недостатков - шаблон приходится дробить на состовляющие.

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

читал бегло, поэтому переспрошу.
то есть, вы всегда пишите так:

<table> <?php $q = mysql_query($sql); while($r = mysql_fetch_assoc($q)){?> <tr><td><?php echo$r[$field]?></td></tr> <?php}?> </table>

?

Ну прошу простить великодушно.)) Просто Вы оказались в нужном месте в нужное время. ;)
У каждой попытки разделить бизнесс-логику и представление есть свои недостатки. И у классических шаблонов, и у нативных, и у Вашей схемы тоже.
С этим нужно смириться, се ля ви.
Рассуждения вышеозначенного товарища на тему "шаблонизатор - это круто, остальное шлак" вызывает как минимум умиление))).

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

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

Вся беда таких как Вы ярых фанатиков шаблонизаторов в том, что вы попутали понятие
"разделить бизнесс-логику и представление" с понятием "разделить PHP И HTML"

Я ни разу ни где не написал, что логику и вывод делить не нужно. Разумеется нужно. Более того, нужно делить как можно тщательнее, по возможности исключив из шаблонов логическую состовляющую. Ведь верстальщик по сути своей - дизайнер. Художник, если хотите. (Конечно, если вы работаете с верстальщиками-программистами, остается посочуствовать). А у художника мышление абстрактное и алогичное, на то он и худождник. Всяческие логические рамки, в которые его кто нибудь попытается загнать, вредять процессу творчества. Ему должно быть комфортно.

И так, пункт первый - удобство разработки.

Что же называете удобным и комфортным Вы. А вот это:

<ul class="list">     {foreach from=$sites item=site}     <li>{$site.URL}/?id={$site.id}</li>     {/foreach} </ul>

То есть по сути тот же логический язык. Ведь это тоже самое, что и это:

<ul class="list">     <?php foreach( $sites as  $site){ ?>     <li><?php echo $site['URL']; ?>/?id=<?php echo $site['id']; ?></li>     <?php } ?> </ul>

только написанное на птичьем языке. Та же самая логика, то же самое смешение коней и людей. Просто завуалированно, мол это не PHP, а значит не логика.
Она, родимая, она. И никуда Вам от неё не деться.
Так что заявления плана
"Шаблонизатор делит бизнесс-логику и представление" несостоятельно.
Справедливости ради нужно отметить, что Вы применяете другие термины:
"Разделить бизнесс-логику с логикой представления." Ну и с чем боролись, на то и напопролись (См код выше) Подменили понятия (один логический язык другим) и считаем, что произошло разделение. А верстальщику ни кисло ни холодно от того, что там вместо дескрипторов фигурные скобки. Да, короче запись, но:
Ему логика в шаблоне вообще не нужна.

Так что первый пункт о удобстве разработки сильно надуман. Это привычнее для Вас, но это не значит удобнее. Вот у господина Loki другое видение удобства, у kosta_in_net третье... Сколько людей. столько шаблонизаторов мнений. У меня и моих соратников тоже свое мнение. И мы считаем удобным натив. По возможности без логической составляющей.

По крайней мере у такого подхода есть простор для маневра - можно писать в шаблон циклы, а можно вынести в отдельные файлы. Чего никак не позволяет костный шаблонизатор. Там померла, так померла. Будь добр придерживаться суррогатного синтаксиса.

Пункт 2. Удобство поддержки.
Ну и кому, позвольте полюбопытствовать это удобно?
Вам. И только Вам. Потому что это Вами разработанные шаблоны, с применением шаблонизатора Blitz . Или господину Loki , потому что это его шаблонизатор. Или господину kosta_in_net, потому что это его схема.
А мне не удобно. И уверен - большенству тех, кто видит этот код впервые, неудобно так же. Потому что прежде чем разобраться в логике шаблона, придется разбираться в логике шаблонизатора. И в его синтаксисе.
Вот Вы сейчас скажите - выучить язык шаблонизатора нужно всего один раз. Ан нет. Если бы. Все дело в том, что этих шаблонизаторов пруд пруди, начиная от хваленой СМАРТИ заканчивая самописными шедеврами. Вот про Ваш Blitz я впервые слышу допустим. А совсем недавно так же точно другой апонент охал и ахал по поводу PHPTAL и говорил, что круче только яйца. И так у всех - куча шаблонизаторов, куча языков, куча синтаксисов, куча мнений.
Так что об удобстве поддержки говорить не приходится. Это было бы удобным, если был бы стандарт. А так это удобно узкому кругу лиц, которые выбрали одну схему и фанатеют от неё.
Так что не убедительно.

3. Производительность. Ничего не скажу про Blitz, но одно знаю точно. Никогда дополнительный функционал не даст прироста в производительности. Если это не акселератор конечно. Это акселератор? Нет. Так что вряд ли.
Ну и даже пусть разница незначительна. Во первых, не Вы ли несколькими постами выше позволили себе это высказывание:

Просто в моей идеологии программист должен писать минимум лишнего кода,

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

4. Безопасность. Тут да, шаблон по Вашей схеме пассивен, исполняемый код туда не сунуть. Но.
Так ли страшен черт, как его малютки? Какой глобальный катаклизм может вызвать злобный верстальщик и тать, засунувший под покровом ночи исполняемый код в шаблон. Дропнуть базу? Снести весь сайт с хоста? Вирус запустить?
Ну право смешно. На то есть бэкапы. А он тут же будет пойман и бит. Ни один человек в здравом уме и рассудке такого не совершит. А уж если Вам приходится оглядываться на таких сослуживцев и всячески страховать свою спину от предательских плевков, то во первых я Вам сочуствую, а во вторых это не поможет. Если человек решил напакостить - он найдет способ. Допустим вместо красивой логики шаблона напишет огромными буквами: НАЧАЛЬНИК КАЗЕЛ, Эфект даже круче, чем пара часов остановленного сайта.

Надумано это и притянуто за уши.

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

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

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

1) спор о том, делать шаблонизатор или писать код напрямую, считаю глупым: каждый др...ет как захочет.
2) вставки типа {TITLE} могут вызывать проблемы, если на странице присутствует яваскрипт с if(){} и т. д.
3) Мне кажется более разумным делать вставки как <!--var--> тогда даже при открытии страницы просто с диска, она не искажается никакими кодами.
4) реализацию переменных в итоговой странице считаю лучше всего делать таким образом:
$search=array(
'<!--var1-->',
'<!--var2-->',
'<!--var3-->',
'<!--var4-->',
'<!--var5-->',
'<!--var6-->'
);

$replace=array(
$var1,
$var2,
$var3,
$var4,
$var5,
$var6,
);

$text=str_replace ($search,$replace,$text);

При этом, вместо $var1 может быть "что-то", или function1(), или что угодно.
При таком подходе интерпритироваться будут только заранее предопределенные метки и, например <!--Rating@Mail.ru counter--> не будет пытаться разименоваться как специальная переменная шаблона.