Очередное столкновение логики представления с логикой приложения.

texrdcom

Новичок
Прочитал топик интерестный согласен с Фанатом
как не крути а представления от логики четко не отделить,
в инете видел интереструю вещь человек кодировал
таблицу какую надо нарисовать с помощью букв тоесть функция выглядела так
PHP:
function table($table,$style='',$values='') 
	{
	if(isset($this->cache[$table]))
	{ 
	if($values=='')$values=&$this->data;
	$values['nbsp']=' ';
	$values['style']=($style)?" class='".$style."'":"";
	return preg_replace("/\[(\w+)\]/e", "\$values['\\1']",$this->cache[$table]);	
	}
	if(preg_match_all("/\((\w+)\)|\[(\w+)\]/",$table,$matches)){ 
     		$values['style']=($style)?" class='".$style."'":"";
     		$rowspan=array();
     		if($values=='')$values=&$this->data;
     		$values['nbsp']=' ';
     		 // WARNING! REVERSE table construction.
     		$out=(preg_match('/\}$/',$table))?"</table>\n":"";
     		for ($i = count($matches)-1; $i > 0; $i--){
     		$el=($i>1)?'td':'th';
     		for ($j = count($matches[$i])-1; $j >= 0; $j--){
     		if(strlen($matches[$i][$j])){ 	
     			$out="</tr>\n".$out;
     			$cols=1;
     			for($l = strlen($matches[$i][$j])-1; $l >= 0 ; $l--){
			$a=$matches[$i][$j]{$l};	
     			if(isset($matches[$i][$j-1]{$l})&& $j!=0 && $a==$matches[$i][$j-1]{$l}) @$rowspan[$a]++;
     			if(($l==0)||($l>0 && $a!=$matches[$i][$j]{$l-1})){
     			$cs=($cols==1)? "":" colspan='".$cols."'";
     			$cl=" class='".$a."'";
     			$search[$a] = (isset($values[$a])) ? "[".$a."]" : "[nbsp]"; 
     			if (isset($rowspan[$a])&&(($j!=0&&$a!=$matches[$i][$j-1]{$l})||($j==0))){ 
     			$rs=" rowspan='".((int)$rowspan[$a]+1)."'";
     			$rowspan[$a]=1;
     			$out= "<".$el.$cs.$rs.$cl.">".$search[$a]."</".$el.">\n".$out;      
     			} else $rs="";  
     			if (!isset($rowspan[$a]))$out="<".$el.$cs.$cl.">".$search[$a]."</".$el.">\n".$out;      
     			$cols=1;
     			}else $cols++;}
     			if($table{0}=="{")$out= "<tr>\n".$out; else $out= "<tr[style]>\n".$out;
     		}}}
		$out=($table{0}=="{")?"\n<table[style] border='1'>\n".$out:$out;
		$this->cache[$table]=$out;
		return preg_replace("/\[(\w+)\]/e", "\$values['\\1']", $out);
		}
		else mess('cannot render table ['.$table.']','warn');
	}
// Таблица обозначалась так
$table = 
 '{(LCR)'
 .'[qwe]'
 .'[asd]'
 .'[mmm]'
 .'[zrt]'
 .'[zfg]'
 .'[zvb]}';
Более подробно

но если глянуть со стороны (и послушать высказывания "это миф что можно отделить полностью логику от представления - и это правильно так как мы стараемся соединить php - html - две разные вещи!")
Получаеться что все выше описанные методы доступны в том же smarty - можно его использовать, или написать свой похожий шаблонизатор!.

-~{}~ 12.05.05 14:01:

Более подробно: http://xpoint.ru/forums/development/analysis/thread/28649.xhtml
 
Очередной раз увидил отсутствие плюсов в смарти =)
В Xtemplate я делаю так:
<table>
<!-- BEGIN: row -->
<tr>
<!-- BEGIN: col -->
<td></td>
<!-- END: col -->
</tr>
<!-- END: row -->
<table>
По наглдяности это совсем не уступает приведенному тобой коду (ИМХО).
За то:
а) Логики не содержится в принципе (а foreach я считаю уже логика).
б) Я могу ВСЕ таблицы оформить таким образом, дизайнеру же достаточно знать название блока родителя (т.е. таблица еще оформляется отдельным блоком, например news).
 

Фанат

oncle terrible
Команда форума
Да не, Дим. Вопрос-то остался нерешённым.
Так что с того места, когда человек меня поставил в тупик именами переменных - можно тему поразвивать =)

Во, кстати. мысль пришла.
Имена переменных - это то, что идёт от программера к верстаку. А имена блоков - назад, в программу.
То есть, требуется обратная связь. То есть, верстала самостоятельно никакую логику добавить в срипт не может - постоянно должен дёргать прогера.
 
Фанат
Не согласен с последним. В смысле, не согласен, что это минус (почему это не минус см. в конце постинга)
ИМХО, разница минимальна. Что в твоем случае идет перебор форичем, что в моем - блоком.
Все равно, верстальщик имеет некую сущность (блок, эелемент массива - не важно), которую он всего лишь может втупую вывести (или не вывести).

Я пропогандирую блочные шаблонизаторы именно по одной простой причине:
Они более просты именно в плане переговоров и договоренностей с верстальщиком.

Я в подобных дискуссиях очень люблю вспоминать, одну работу, на которой дизайнер еще и верстал.
Так вот, все диалоги с ним происходили подобным образом:
"А где хранится шаблон списка новостей?"
"Блок news_list в шаблоне cont.tpl".
"Понятно".

Все! Внутри блока news_list опять идут стандартные блоки "row", "col" (если надо), и переменная массив {item} с индексами {item.name}, {item.id}, {item.url}(!!!) etc.

А теперь представь, есть страница, на которой выводится список:
а) Новостей
б) Статей
в) Категорий каталога в три столбца
г) Частопокумаемые товары (top10).
И представь, сколько надо усилий потратить, что бы объяснить верстальщику в какой переменной что хранится, и какая переменная имеет какую структуру.

У Меня же такой проблемы нет. Ибо для объяснения, мне надо просто сказать 4 блока, а дальше все стандартно.

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

З.Ы. И, кстати, за что я люблю Xtpl - он очень придирчив к синтаксису. Это заставляет делать шаблоны жестко структуированными, что является безусловным плюсом в понимании шаблона.
 

IntenT

SkyDiver
кто готовит первый, технический вариант шаблона?
и готовится ли он вообще?
 

Alexandre

PHPПенсионер
Интересно, сколько процентов народу в этом форуме работают с отдельным верстальщиком
HEm когда я работал в интернет агенстве, то у нас был верстальщик, который все это и делал.

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

-~{}~ 12.05.05 19:18:

У Меня же такой проблемы нет. Ибо для объяснения, мне надо просто сказать 4 блока, а дальше все стандартно
Дим, в смарти тоже можно выводить поблочно. Это не рационально, для большогй страницы (где много блоков ) использовать один бооольшой шаблон.
а если блоки повторяются в др. страницах???

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

В результате отлаживаешь по отдельности модуля:
а) Новостей
б) Статей
в) Категорий каталога в три столбца
г) Частопокумаемые товары (top10).

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

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

:)
 
Alexandre
Я не хочу на текущий момент говорить рационально или нет, для большой страницы один шаблон. У нас с тобой совершенно разные стили и принципы программирования. Лично я с некоторых пор вообще не признаю понятия "модуль" в таком контексте, в каком его применяешь ты.

Поповоду шаблонов, у меня вообще стандартно один-два шаблона(не файла шаблона а именно шаблона) на весь сайт. Ничего, работает. Даже неплохо работает.

IntenT
А что подразумевается под "первым, техническим вариантом шаблона"?

-~{}~ 12.05.05 20:27:

Вообще мы опять тему не туда унесли, как мне кажется =(
 

Crys

Двинутый новичок
[OFFTOPIC]

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

И вопрос по Xtpl.
В Smarty я ввел функцию "load_plug"
[q]{load_plug name="name_plug" param1=value1 .... paramN=valueN}[/q]

Если такая строчка вставлена в шаблон - загружается скрипт "name_plug", который обрабатывает параметры, устанавливает переменные для шаблона name_plug.tpl и подключает его. Все переменные шаблона name_plug.tpl - используются только этим шаблоном. Т.е, например, возможна такая фигня:

Код:
main.php

<?
$tpl->assign("test","bla-bla");
$tpl->display("main.tpl");
?>

main.tpl
{$test}<br>
{load_plug name=plug}
{$test}

plug_plug.php
<?
$tpl->assign_p("test","Not bla-bla");
?>

plug_plug.tpl
{$test}<br>


//Output
 bla-bla
 Not bla-bla
 bla-bla
Также в Smarty я ввел фукнцию для быстрой обработки данных из mysql
Выглядит так:

Код:
{while_res from=news}
<div class="newstitle">
<a href="news/show/{$row.id}/">{$row.title}</a>
</div>
<div class="content">
{$row.text}<p>
<div align="right">Posted by {$row.poster} at {$row.date}</div>
</div>
{/while_res}
Позволило значительно увеличить скорость выполнения скрипта.


На Xtpl такое возможно?
 

ONK

Пассивист PHPСluba
Crys, такое возможно на ПХП, что собственно и доказывает твой смарти.

Я тоже придерживаюсь метода шаблонизирования похожего на тот, о котором говорит Дмитрий Попов, то есть полное отсутствие логики в шаблонах.
Мне больше нравится полное отделение программного кода от дизайна, о чём я неоднократно писал и приводил всевозможные доводы.
Если в таком шаблоне блоки размещены в логически верном (я бы даже сказал в единственно разумном) порядке, то верстальщик сам способен догадается какой блок за что отвечает. Тоже самое относится к именам переменных размещённых в блоках.

У меня есть шаблон, из которого генерируется более 50 различных страниц, 20 из которых использует уникальный набор блоков из этого шаблона. При этом полное время генерирования страниц сопоставимо со временем парсировки ПХП интерпретатором исходников смарти. -)
 
Crys
ONK ответил правильно. В чистом Xtpl такое невозможно, т.к. это полностью пассивный шаблонизатор. Написать модуль xtpl, которое позволит такое делать абсолютно без проблем.
Но лично я считаю такой подход абсолютно неприемлимым.
 

Alexandre

PHPПенсионер
пример: куда пихнуть логику

перейдем к практике:

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

строки с Пользователями должны быть помечены цветом:
красным - отключенные (должники)
желтым - кандидаты на отключение ( остатки меньше чем среднесуточное потребление услуг пользователя)
белым - все остальные

Вопрос:
где формировать цвет подсветки строки:
в коде ( как параметр цвета для bgcolor)
или в шаблоне, по некоторому признаку, завсящему от значения поля строки ($is_connect, $is_realm ).
 

ONK

Пассивист PHPСluba
Alexandre, Могу лишь ещё раз кратко описать мою позицию по данному вопросу. С моей точки зрения, шаблон это средство вынесения html кода за пределы программного кода скрипта. Шаблон в любом случае тесно связан со скриптом отвечающим за логику представление. Надо просто явно обозначить эту связь, выделяя программные код отвечающий за сопровождение шаблона в отдельную процедуру, в которую входит получение данных, их подготовка и инициализация данными шаблона. При этом все вопросы, которые касаются только внешнего вида страницы, могут быть решены исправлением шаблона.

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

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

Alexandre

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

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

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

Хочу отметить, что интерфейс данных ( буть то массивы для smarty или данные xml для XSLT) НЕ изменился

Меняем только внешнее представление

-~{}~ 13.05.05 13:29:

Поповоду шаблонов, у меня вообще стандартно один-два шаблона(не файла шаблона а именно шаблона) на весь сайт.
Дим, чем отличается шаблон от файла? Поясни концепцию.

я вот придерживаюсь концепции:
один функциональный модуль - один файл (класс)
один ему соответствующий ему шаблон ( в одном файле )

генеральный модуль -
соответствующий ему шаблон (отдельный файл )
 
Alexandre
Я знаю как минимум два решения:
Первое, то, что уже сказал ONK (т.е. цвета вообще должны задаваться в админке/в конфиге). Его я считаю наиболее верным.
Второе: Создавать сабблок, в котором и задаётся бекграунд.

Дим, чем отличается шаблон от файла?
Тем, что шаблон соотвествует странице в целом.

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

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

Alexandre

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

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

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

IntenT

SkyDiver
Дмитрий Попов
А что подразумевается под "первым, техническим вариантом шаблона"?
Это тот вариант шаблонов, который передается верстальщику для натягивания на него порезаного хтмля. Насколько я понимаю, этот вариант шаблонов готовит програмист. Он-же закладывает в эти шаблоны обращения ко всем требуемым по ТЗ переменным.

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


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

Мое мнение - код должен достать данные, обработать, и передать куда-то, чтобы отобразить их (например шаблонизатору).
Как отобразить - полностью дело этого шаблонизатора.
 
Сверху