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

Alexandre · 4 Авг 2005

тот же дизайнер сможет с лёгкостью править конфигурационный файл, который можно кстати сделать как *.ini.

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

Лисю, может я привел и простой пример, но речь идет совершенно не о просых проектах

Лисю · 4 Авг 2005

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

комментарии ещё никто не отменял

но речь идет совершенно не о просых проектах

тогда пример приведи, ибо что-то говорить о том, чего нет, сложно..

BeGe · 4 Авг 2005

Автор оригинала: Alexandre

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

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

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

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

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

Не правильно представили данные для обработки. Если Вы хотите отобразить массив в виде таблицы - то дайте шаблону готовую матрицу, а не линейный массив. Хотя если у Вас получиться написать достаточно лёгкую и понятную систему отрисовки линейного массива в виде таблицы - не проблема. (это всего лишь пример и не касается Вашей задачи)

Автор оригинала: Alexandre
BeGe вот я и хочу понять - где эта грань,

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

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

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

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

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

ONK · 4 Авг 2005

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

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

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

ПС.
Лисю, ваше первое сообщение трудно читать без улыбки, так и хочется сказать, что вам просто "это" ещё не показали, что она (логика) вам ничего не должна. И особенно хочется посмотреть на "чистые данные".

Alexandre · 4 Авг 2005

Хотя если у Вас получиться написать достаточно лёгкую и понятную систему отрисовки линейного массива в виде таблицы - не проблема

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

технологии представления данных расширяются и усложняюся

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

BeGe · 4 Авг 2005

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

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

ключевое слово "понятную" (поправка: не для Вас).

Sherman · 5 Авг 2005

А к какому варианту относится следующая штука(код абстраткный):

Код:

===========================
//data layer:

class DataItem
{
   struct dataItem;
}

class DataBizLogic
{
   DataItem obj;
  method  GetDataItemByID(id)
  {
     //fill DataItem object with data;
  }
}
======================================
//template:

<table>
  <-- begin list_item -->
  <tr>
    <td>
      {list_item}
    </td>
  </tr>
  <-- end list_item -->
  <-- begin list_item_alt -->
  <tr>
    <td>
      {list_item_data}
    </td>
  </tr>
  <-- end list_item_alt --> 
</table>

====================================
//render logic:

//load data

$dataObj = new DataBizLogic();
$dataObj->GetDataItemByID(id);

//parse and out
$numItem =count( $dataObj->dataCollection); 
$tplObj = new Template("template.tpl");

for($i = 0; $i<$numItem;i++) 
{
   if ($i%2 == 0)
   {
      $listItem = $tplObj->fetchBlock("list_item");
   }
   else
   {
     $listItem = $tplObj->fetchBlock("list_item_alt");
   }
  $listItem->assign("list_item_data", $dataObj->dataCollection[$i]->dataField); 

   $tplObj->assign("list_item", $listItem );
   $tplObj->assign("list_item_alt", "");
   $listItem ->reset();
}

Tor · 5 Авг 2005

к правилам форума, однозначно

ONK · 5 Авг 2005

Sherman, ты привёл "контроллер шаблона" + шаблон без логики. То есть это 2-й вариант.

Sherman · 5 Авг 2005

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

А в мелких приложениях лучше вообще обойтись вариантом inline-кода(т.е. обычные вставки в HTML).

И еще, небольшое добавление.

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

А второй момент, это квалификация дизайнера/верстальщика, котоырй и должен заниматься слоем представления. А то ведь бывает, что человек знает только HTML, и проще самому написать на php за 2 минутки то, над чем он будет сидеть пол дня.

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

Резюмируя.

Применение второй схемы оправдано:

1. Когда нужна гибкость и расширяемость, соблюдение отраслевых стандартов(коробочные продукты, библиотеки и т.д.)
2. Есть время на реализацию.
3. Есть квалификация.

EugeneS · 5 Авг 2005

а по мне так вариант выше так это чистый MVC при условии что "//data layer:" это модуль работающий с базами соуществляющий вычисления и прочее в том же духе
"//render logic:" чистой воды контроллер получающий/передающий данные из/в модуль/темплэйт

"шаблон собственно говоря и есть шаблон ..."
вот только цикл из контроллера по моему надо перенести в шаблон а шаблону из контроллера ассигнить массив ...

PS: представления не имею что делают эти fetchBlock но хочется верить что подгатавливают данные для шаблона/модуля только вот как то оно здесь в контроллере немного всё странно перемешано на первый взгляд ....

вот такая вот моя имха

Sherman · 6 Авг 2005

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

//data layer
В данном случае это именно то самое. Т.е. все операции с бд, которые касаются нашего объекта DataItem инкапсулированы в класс бизнес логики.

Если быть точным тут у нас гибрид data logic/business logic.

p.s. Cамое интересное, что я никогда не вникал в паттерн mvc

AlMaz · 7 Авг 2005

Nawel po etomu voprosu interesnuu stat'u (na angliyskom):
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

Avtor - razrabotchik generatora kompilyatorov ANTLR i wablonizatora StringTemplate. Tak chto chelovek ne tol'ko teoretik, no i praktik.

Лисю · 7 Авг 2005

шаблон без логики

как много я такое слышу.

Объясните дураку, скажите, как можно тогда в "БЕЗлогичных" шаблонах реализовать такое:

Если имя пользователя "Федя", выводим "Федя" красным цветом
Иначе - выводим "Федя" синим

ONK · 7 Авг 2005

....Если имя пользователя "Федя", выводим "Федя" красным цветом
Иначе - выводим "Федя" синим ....

Лисю, у вас явные проблемы с логикой принятия решений.

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

Лисю · 7 Авг 2005

можно ввести переменную отвечающую за цвет

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

можно выделить два отдельных блока.

как?

ONK · 7 Авг 2005

Лисю, Вам всегда надо всё на пальцах объяснять?

Код:

<!-- BEGIN 1 --!><font color='red'>{user_name}</font><!-- END 1 --!>

<!-- BEGIN 2 --!>{user_name}<!-- END 2 --!>

Лисю · 7 Авг 2005

понятно, спасибо.

<мысли вслух>хм.. чем это лучше тривиальных if-else конструкций? :/</мысли вслух>

Денч · 7 Авг 2005

чем это лучше тривиальных if-else конструкций

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

Лисю · 7 Авг 2005

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

хы-хы..

в чем разница то между

<!-- BEGIN 1 --!><font color='red'>{user_name}</font><!-- END 1 --!>

<!-- BEGIN 2 --!>{user_name}<!-- END 2 --!>

и любой логикой, будь то на том же PHP:

PHP:

<? if(...): ?>
   <font color='red'>{user_name}</font>
<? else: ?>
{user_name}
<? endif; ?>

ради мнимой идеи отделения ТРИВИАЛЬНОЙ логики от шаблона люди пишут интерпритаторы шаблонов. ух.

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

PHPПенсионер

Лисю

Guest

Вождь Апачей, блин (c)

Пассивист PHPСluba

PHPПенсионер

Вождь Апачей, блин (c)

Mephi

Новичок

Пассивист PHPСluba

Mephi

Новичок

Mephi

AlMaz

Guest

Лисю

Guest

Пассивист PHPСluba

Лисю

Guest

Пассивист PHPСluba

Лисю

Guest

Новичок

Лисю

Guest