шаблон c собачкой (@) или все же без

[0xHH]

http://www.melnikoff.ru/template-this/

 

[antivir]

http://www.melnikoff.ru/template-this/

+1

отличная статья

 

[Фанат]

Дима Смирнов ещё 4 года назад такую написал.

 

[antivir]

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

например, сделать список: 1, 2, 3, 4, 5

<?
$array = array(1,2,3,4,5);
$co = count($array)-1;
?>

<? foreach($array as $k=>$v): ?>
   <?=$v?>
   <? if($k != $co): ?>
   		,&nbsp;
   <? endif; ?>
<? endforeach; ?>

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

 

[0xHH]

.

 

[Фанат]

о, начался детский лепет в другую крайность

 

[bgm]

Шаблон-шмаблон. PHP - это один из элементов веб-конструктора. И желательно стремиться не к каким-то абстрактным концепциям, а к общему балансу. Иначе можно построить башню из песка.

antivir
Что это у тебя за высосанный из пальца адский пример?

 

[denver]

Автор оригинала: antivir
и присказки о том, что нужно отделять код оформления от логики кода представления пора забыть.

а может в оригинале присказки было "...отделять оформление кода от представления логики кода..." ?

 

[С.]

antivir

<?=implode(',&nbsp;', $array)?>

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

 

[antivir]

С.
Это ИМХО не правильно. Не нужно вводить в шаблон функции языка PHP. Это уже получается смешение самого PHP и HTML.

Верстальщик может незнать, что такое implode, а выносить в КОД ПРОГРАММЫ 'mnjn кусок нельзя, ибо возможно понадобится доработать шаблон вsdjlf? скажем, вместо запитой, поставить дефис.

 

[Фанат]

antivir
твой пример высосан из пальца.
именно поэтому его никто не понял.
если бы ты
а) привёл реальный пример
б) не бредил про разделение с отделением
к тебе бы вопросов не было.

-~{}~ 21.07.06 10:15:

вот реальный пример постраничного вывода

<? foreach ($PAGES as $i): ?> 
  <? if ($CURRENT_PAGE==$i):?>
   <?=$i?>
  <?else:?> 
   <a href="?page=<?=$i?>"><?=$i?></a> 
  <?endif?>
<?endforeach?>

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

 

[antivir]

Фанат
мой пример был оринтирован на наличие запятой после каждой цифры

забейте

 

[С.]

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

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

 

[0xHH]

Пример постраничного вывода:

<p align=right>
{if $previouspage eq 1}
	<a href="/messages/">{$text.txt_next_records}</a>
{elseif $previouspage neq 0} 
	<a href="/messages/page/{$previouspage}/">{$text.txt_next_records}</a>
{/if}
|
{if $nextpage neq 0}
	<a href="/messages/page/{$nextpage}/">{$text.txt_previous_records}</a>
{/if}
</p>

 

[antivir]

0xHH
это што?

 

[StUV]

у меня к этой проблеме собственное (достаточно спорное) отношение...

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

как я заметил - достаточно спорное отношение - но имхо в шаблон должны идти только те данные, которые запросил клиент - не больше _и_ не меньше
=)

 

[WP]

С.
> и производительность
Разве?
antivir
"... а это не моя жена".
> если шаблон не воспользовался переданным в него значением - так же фатал...
Почему?
StUV
> но имхо в шаблон должны идти только те данные, которые запросил клиент - не больше _и_ не меньше
Оно не спорное, оно ошибочное. Шаблон может использовать какие-то данные, а может не использовать, это его личное дело, бизнес-логика отдает результат на растерзание логике представления, а она уже может с улыбкой Джаконды написать "lol" не используя при этом никаких данных. Это её личное дело.

 

[StUV]

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

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

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

-~{}~ 24.07.06 11:32:

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

вот это и вызывает споры
но с тех пор, как я это реализовал - "жить стало проще"

 

[WP]

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

А какие тут могут быть споры? Ошибка в самой смысле того что ты сделал. В корне. Шаблон это же отдельная штука которая может вести себя как угодно согласно логике представления. Мало ли что дизайнеру в голову взбрендит. Вот если шаблон пробует взять несуществующую переменную - фатал оправдан. Т.к. для этого значения не создана бизнес-логика, а значит оно не может быть обработано шаблоном и представлено.
Конкретный пример: только что сделал чтоб при наведении на топик появлялся летающий span содержащий первый пост топика. Естественно это через AJAX, а другом конце шаблон Smarty. Дизайнер может захотеть показывать имя пользователя, или не захотеть. Что ж ему, фатал значит, да?

 

[Фанат]

WP
если ты до сих пор не понял, то товарищ StUV как раз и придумал себе механизм, который облегчает написание шаблонов без багов.