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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

технологии представления данных расширяются и усложняюся ;)
а уровень тех, кто работает с шаблонами - остается прежним
Нажмите для раскрытия...
ключевое слово "понятную" (поправка: не для Вас).
 
А к какому варианту относится следующая штука(код абстраткный):

Код: 
===========================
//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();
}
 
Sherman, ты привёл "контроллер шаблона" + шаблон без логики. То есть это 2-й вариант.
 
Ну вот значится я тогда за второй вариант в приложениях среднего и крупного масштаба, а также с типовых приложениях, для которых большая часть кода уже готова.

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

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

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

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

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

Резюмируя.

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

1. Когда нужна гибкость и расширяемость, соблюдение отраслевых стандартов(коробочные продукты, библиотеки и т.д.)
2. Есть время на реализацию.
3. Есть квалификация.
 
а по мне так вариант выше так это чистый MVC при условии что "//data layer:" это модуль работающий с базами соуществляющий вычисления и прочее в том же духе
"//render logic:" чистой воды контроллер получающий/передающий данные из/в модуль/темплэйт

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

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

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

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

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

p.s. Cамое интересное, что я никогда не вникал в паттерн mvc:)
 
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.
 
шаблон без логики
Нажмите для раскрытия...
как много я такое слышу.

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

Если имя пользователя "Федя", выводим "Федя" красным цветом
Иначе - выводим "Федя" синим
 
....Если имя пользователя "Федя", выводим "Федя" красным цветом
Иначе - выводим "Федя" синим ....
Нажмите для раскрытия...
Лисю, у вас явные проблемы с логикой принятия решений. :)

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

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

<!-- BEGIN 2 --!>{user_name}<!-- END 2 --!>
 
понятно, спасибо.

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

в чем разница то между
<!-- 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; ?>

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