Меню
Что нового?

логика представления и логика выполнения. Что куда???

Alexandre

PHPПенсионер
логика представления и логика выполнения. Что куда???

вопрос много обсуждался, и все-же????

есть следующая задача:
отобразить скисок клиентов и кнопку добавить\изменить.
если список пуст, то наименование кнопки должно отображаться "добавить" иначе "изменить".

за HTML представление отвечает шаблон

Вопрос следующий:

(вариант 1)
вводить в шаблон ( тип шаблонизатора значение не имеет) логику: если список пуст, то имени кноспки присвоить "новый"
иначе "изменитоь"

(вариант 2)
или эту логику переместить в код (логика исполнения), а в шаблон ввести дополнительную переменную и назначить значение данной переменной имени кнопки <input type="button" name="<%SET ButtonName%>">

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

Yaguan

пилот
По мне - однозначно первый вариант предпочтительнее как более гибкий.
 
[DAN]

[DAN]

Старожил PHPClub
По MVC работает 1-й вариант.
Во втором варианте ты уже влезаешь во View из контроллера, что не есть good.
 

Макс

Старожил PHPClub
Во втором варианте ты уже влезаешь во View из контроллера, что не есть good.
Нажмите для раскрытия...
View и шаблон - не всегда одно и тоже.

Некоторые разработчики специально слой "Представление" разделяют на 2 части :
- шаблон
- контроллер шаблона
Шаблон не имеет никакой логики, она вся выносится в контроллер представления
 

ONK

Пассивист PHPСluba
Макс, да, есть такие. -) И они считают, что такой вариант ещё более гибкий и удобный чем смешивание в шаблоне логики и HTML кода.
 

Alexandre

PHPПенсионер
ещё более гибкий и удобный чем смешивание в шаблоне логики и HTML кода
Нажмите для раскрытия...
вот и меня интересует, хорошо ли в шаблоне делать смешивание логики и HTML кода.

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

Yaguan

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

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

BeGe

Вождь Апачей, блин (c)
Есть две крайности.
первая - ты все пишешь в коде - как это делал на заре свой юности.
второая крайность - ты выносишь всё представление (никапли логики в шаблоне).

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

Лисю

Guest
вот и меня интересует, хорошо ли в шаблоне делать смешивание логики и HTML кода.
Нажмите для раскрытия...
от Логики в шаблоне уйти нельзя. Пора бы это уже осмыслить.

а вот если другой человек будет разбираться или дизайнер, которому вся логика по одному месту.....
Нажмите для раскрытия...
Шаблоны сделали не для тупых дизайнеров, а для того, что бы можно было отделить код представления от кода САМОЙ ПРОГРАММЫ, генерирующей ЧИСТЫЕ ДАННЫЕ.

код представления в смарти:
PHP: 
    {if $smarty.session.user and ( $user_type eq "editor" or $user_type eq "admin" )}
       <input type=checkbox name=edit value="y"> edit <br>
    {/if}
где же тут отсутствии логики? От неё уйти нельзя. Она ВСЕГДА будет присутствовать в шаблоне. И ДОЛЖНА там быть.
 
[DAN]

[DAN]

Старожил PHPClub
Alexandre
Скажем, в XSLT присутствует довольно много логических конструкций.
Но ты же в шаблоне не делаешь SQL-выборку и не отрабатываешь алгоритмы.
А простые if/then/else - это совсем не страшно для шаблона. Так же как и решение, какие данные выводить клиенту. Вся "бизнес-логика" зашита у тебя в модели, но не модели ведь решать, как должны выглядеть ее данные.

P.S. некоторые энтузиасты вводят для такого случая т.н. Helper-классы.
 

Alexandre

PHPПенсионер
[DAN], в предыдущем проекте я полностью логику представления переместил полностью в XSLT шаблон,
шаблон стал перегруженным,
а код более простым

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

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

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

часть функциональности вообще реализовал с полтыка,

а вот для реализации некоторых функций пришлось перестраивать структуру шаблонов, вводить новые <xsl:template> на что убил много времени.

если бы шаблоны были простые, на уровне {IF} и {LOOP}, то такая задачка на все заняла бы пару часов

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


хорошо ли ли это??


Шаблоны сделали не для тупых дизайнеров, а для того, что бы можно было отделить код представления от кода САМОЙ ПРОГРАММЫ, генерирующей ЧИСТЫЕ ДАННЫЕ.
Нажмите для раскрытия...
Лисю, что такое чистые данные ??

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

Однако, такие функции как упорядочивание, подсветка, вычисление промежуточных итогов, транспонирование данных (т.е. отображать не в том геометрическом подядке, кокой получен из БД, ну к примеру развертывание одной или более размерности данных по вертикали, или многострочном отображениее данных) и пр. операции отображения данных ???

рационально ли это;)

-~{}~ 03.08.05 19:17:

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

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

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

стоит ли делать сортировку в коде, или это отдать на съедение XSL

короче - где она эта середина ????
 

Лисю

Guest
Alexandre

Вариант 1:
PHP: 
// Скрипт генерирует данные.
// $list_count - флаг, содержащий в себе количество клиентов - ноль или больше.

<input type="submit" name"add" value="<?=($list_count ? "Изменить" : "Добавить")?>" />

Вариант 2:
PHP: 
// [b]Скрипт генерирует[/b] значение $button_name. 

<input type="submit" name"add" value="<?=$button_name?>" />
Приходит дизайнер и хочет изменить надпись в шаблоне на этой кнопке с "добавить\изменить" на "add\edit".
Откроет шаблон 1 и 2. Угадай, в каком случае он ругнётся матом? :)

-~{}~ 03.08.05 20:46:

На базе варианта 2 и появляются уродские шаблонизаторы, авторы которых генерируют в скриптах HTML вместе с текстом, а потом делают что-то типа

PHP: 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
	<title>{title}</title>
</head>

<body>
	<desing>
		<desing>
			<desing>
				{SUPER_PUPER_CONTENT} 
			</desing>
		</desing>
	</desing>
</body>
</html>
и считают, что изобрели шаблон. А на деле получается, что смешали всё в двойной степени сложности.
Скрипт должен отдавать исключительно уникальные данные (записи из БД) и возможно, булевы флаги, не зависящие ни от чего, а наоборот, диктующие шаблону что выводить -- "Добавить" или "Add".

Всё IMHO.
 

ONK

Пассивист PHPСluba
Лисю, вы когда-нибудь слышали о многоязыковом интерфейсе?
И вообще, судя по вашим двум постам, вам бы следовало воздерживаться от оставления здесь ваших сообщений.
 

Gorath

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

Screjet

Новичок
Alexandre
Решение простое: все что отображается на сайте должно быть легкодоступно для правки верстальщиком/оператором.

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

bgm

&nbsp;
Очередная волна...
"Логика, данные, выполнение и представление..."
Хотя и то и другое и третье - это информация.
И любая программа работает с информацией.
И любая программа является информацией.
 

Лисю

Guest
Специально для ONK:

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

Вариант 1:
PHP: 
// Скрипт генерирует данные.
// $list_count - флаг, содержащий в себе количество клиентов - ноль или больше.

// ПЕРВОЕ, что пришло в голову:

// $button_value["add"]["ru"] = "Добавить";
// $button_value["add"]["en"] = "Add";
// $button_value["edit"]["ru"] = "Редактировать";
// $button_value["edit"]["en"] = "Edit";

// Язык интерфейса
$lan = "ru";

<input type="submit" name"add" value="<?=($list_count ?  $button_value["edit"][$lan] : $button_value["add"][$lan])?>" />

Вариант 2:
PHP: 
// [b]Скрипт генерирует[/b] значение $button_name. 

<input type="submit" name"add" value="<?=$button_name?>" />
Приходит дизайнер и хочет изменить надпись в шаблоне на этой кнопке с "добавить\изменить" на "add\edit".
Откроет шаблон 1 и 2. Угадай, в каком случае он ругнётся матом?

Ответ - ни в каком. В переменной $lan уже содержится язык, на котором отображать названия конопок. Но тут - мы вынесли в отдельный массив названия элементов управления, и когда появится необходимость править названия кнопок с "Добавить/Редактировать" на "Зафигачить!/Отфигачить!", то тот же дизайнер сможет с лёгкостью править конфигурационный файл, который можно кстати сделать как *.ini.

Этот метод не далеко отличается отварианта 1 - в скрипте генерируем только УНИКАЛЬНЫЕ данные. Названия кнопок скрипт генерировать не должен.


PS. И попрошу аргументировать свои наезды, а не писать тупо, где кому можно, а где кому не можно писать.
 
_RVK_

_RVK_

Новичок
Alexandre
Если выбирать из двух выриантов, предложенных тобой то 1й однозначно. Насчет нового слоя мжеду контроллером и шаблоном это зависит от реализации движка. У меня в движке для пхп4 шаблон=vbiew. В движке под пхп5 тоже самое, но можно(если нужно) добавить класс, объект которого перехватывает данные из контроллера и передает их во view.
 
Войдите или зарегистрируйтесь для ответа.
Сверху