Концепции шаблонов: 2 подхода

Yurik · 10 Янв 2004

Концепции шаблонов: 2 подхода

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

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

Подход 1.
В шаблоне никакой логики. Только представление. Что и куда вставлять решает полностью программист. В принципе полное разделение труда дизайнер/верстальщик/програмер, но программеру в этой ситуации не позавидуешь. Кроме того что его классы заточены под шаблон и не совсем reusable, в логику приложения попадает логика представления.

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

Какой подход используете Вы и чем Вы это аргументируете? Ибо есть много людей которые исключительно за 1 или за 2 подход.

Повторюсь что речь не идет о конкретном движке, например используя Smarty можно делать и так и так.

Макс · 10 Янв 2004

Мой подход ближе к первому.
В шаблонах использую только метки и блоки.
Не хочу использовать второй метод, так как считаю что при таком подходе можно вообще отказаться от шаблонизаторов и и использовать ПХП:

PHP:

<? foreach ($ar as $k=>$v) { ?>
<tr bgcolor="<?=$colors[$i++ %2];?>">
 <td><?=$k;?></td>
 <td><?=$v;?></td>
</tr>
<? } ?>

Иногда, если нужна универсальность, позволяю себе писать

Код:

func_module('param1','param2')

прямо в шаблоне.
В скрипте регистрируется функция с именем 'module' , шаблонизатор сам вызывает фунцию, и на ее место в шаблоне записывает то что она вернула.
Но это тольк для обеспечения универсальности (например подключение динамических блоков в CMS)

Макс · 10 Янв 2004

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

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

Yurik · 10 Янв 2004

Да, 3-уровневая модель немного оправдывает 1 подход, но опять же программисту некисло в такой ситуации.
1 Уровень - бизнес-логика
2 - логика представления
3 - предсьавление

Yurik · 10 Янв 2004

telepuzik · 10 Янв 2004

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

А за или против - это смотря для чего.

ONK · 10 Янв 2004

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

Sad Spirit · 10 Янв 2004

Re: Концепции шаблонов: 2 подхода

Автор оригинала: Yurik
должна ли быть логика в шаблона, если да - то сколько.

Подход 1.
В шаблоне никакой логики...

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

На самом деле более правильная классификация --- на 'push' и 'pull'. В 'push' шаблонах данные загоняются в шаблон скриптом, он же управляет выводом. В 'pull' шаблонах из самих шаблонов вызываются всеразличные методы, запрашивающие данные.

Но даже целью 'push' шаблонов не должно быть "отсутствие логики в шаблонах", если её там вообще нету, то дизайнеру для чередования вывода цветов в таблице или (недавний пример Crazy, наведший на определённые мысли) для вставки одной и той же переменной просто в страницу и в URL придётся пинать программиста.

Выбор между 'push' и 'pull' --- в большей степени дело вкуса...

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

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

Фанат · 10 Янв 2004

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

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

Yurik · 10 Янв 2004

Трудозатраты несравнимы.

многие люди говорят что их производительность сайтостроения вырастает в 2-3 раза после перехода на шаблоны. А трудозатрат на переход не очень и много.

Фанат · 10 Янв 2004

при чем здесь переход на шаблоны?
где у меня написано, что я не использую шаблоны?
или ты хочешь сказать, что форич чем-то отличается от твоего шаблона номер два? Ага, цветом бантиков и формой скобочек. Кардинальное просто отличие. Убиться веником.

При чем здесь трудозатраты на переход?
Где у меня написано про трудозатраты на переход?
Ты внимательно читал то, что я написал? Про трудозатраты чего?

Yurik · 10 Янв 2004

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

Фанат · 10 Янв 2004

Сам я, кстати, макса невнимательно прочел, прошу прощения.
Он использует первое, чтобы не использовать второе именно так.
Ну а я во втором беды абсолютно никакой не вижу, а вот первое- ТАКАЯ морока, что увольте. Лучше я буду руками дизайн править, чем бегать по десятку отдельных файлов на каждый чих, сделаных только для того, чтобы дизайнера не пугать условным переходом.
Вот пример:

PHP:

<table border="0" cellpadding="0" cellspacing="0" width="90%" align="center">
<? foreach ($data as $row) { ?> 
  <tr>
    <td class="gb_name" width="100%">
      <table border="0" cellpadding="0" cellspacing="0" width="100%">
        <tr>
          <td width="100%" class="menu_a"><? echo $row['name'] ?><? echo $row['city'] ?></td>
  <? if ($row['email']) { ?>
          <td class="menu_a" nowrap>
            <a href="mailto:<? echo $row['email'] ?>">
              <img src="/images/mail.gif" width="25" height="10" alt="написать письмо" border="0">
            </a>
            <img src="/images/zero.gif" width="10" height="10" border="0">
          </td>
  <? } else { ?>
          <td><img src="/images/zero.gif" width="1" height="10" border="0"></td>
  <? } ?>
        </tr>
      </table>
    </td>
    <td class="gb_name_fon" nowrap><? echo $row['date'] ?>&nbsp;&nbsp;</td>
  </tr>
  <tr>
    <td colspan=2><p class="gb"><? echo $row['body'] ?></p></td>
  </tr>
  <? if ($row['answer']) { ?>
  <tr>
    <td colspan=2 align="right">
      <p class="gb_ans"><? $href_class="gb_name"; echo $row['answer'] ?></p>
    </td>
  </tr>
  <? } ?>
  <tr><td colspan="2">&nbsp;</td></tr>
  <? if($admin) { ?>
  <tr>
    <td colspan=2>
      <font size=-1>
      <? echo $row['ip'] ?>
      <a href="<? echo $_SELF.'?action=delete&id='.$row['id'] ?>">удалить</a>
      <a href="<? echo $_SELF.'?action=edit&id='.$row['id'] ?>">редактировать</a>
      <a href="<? echo $_SELF.'?action=comment&id='.$row['id'] ?>">ответить</a>
      </font>
    </td>
  </tr>
  <? } ?>
<? } ?>
</table>

это отдельный файл.
Весь хтмл рисовала хозяйка гостевой (в частности, для любителей оффтопика, все претензии по хтмл - к ней).
точнее, перерисовывала из моего схематичного

Пример с емейлом очень показательный.
Сначала я хотел всю логику сделать сам, но она захотела оформить по-своему.
пришлось добавить в код условный переход.
Или мы имеем красивое гибкое оформление, или тупого верстальщика.
Обычно люди предпочитают первое.
Кстати, ONK, о верстальщиках.

Дизайнер и логика, вещи плохо совместимые.

С точно таким же основанием можно заявить, что дизайнеров наши проблемы шаблонов вообще не касаются. Диайнер сидит в фотошопе.

Фанат · 10 Янв 2004

Я не знал чего вы имели ввиду

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

Demiurg · 10 Янв 2004

Я предпочитаю использовать второй способ, все таки знаешь где у тебя что и куда лезть в случае чего. Смапти как раз к этому распологает, плюс ко всему все текстовые константы хранятся в конфигах, что резко упрощает их редактирование и смену языка. Хотя конечно, как уже было сказано, есть свои минусы: дизайнер должен иметь представление о программировании на простейшем уровне. Но ведь программистам тоже необходимо знать html, так что мы квиты

bzik · 10 Янв 2004

Вобще не представляю как использовать пуш-модель в чистом виде... Либо шаблонов плодить немеряно, либо кучу дизайна/данных в код запихивать.

[DAN] · 11 Янв 2004

Я предпочитаю использовать XML+XSLT.
Классы моделий нагенерили данных, классы представлений отдали шаблоны для этих данных, контроллер всё собрал воедино и отдал пользователю.
Очевидно, в этом случае используются плюсы как первого, так и второго подхода.
Как то:
1) Только представление (XML). Что и куда вставлять решает полностью программист (XSL).
Но отсутствует минус того, что "классы заточены под шаблон и не совсем reusable". В этом случае классы заточены под данные, и только под них (читай "формат данных"). В шаблоне лишь прописано, как эти данные представить.

2) "В шаблоне есть логика представления." Что позволяет существенно упростить код и вынести всякие "рюшечки" в XSLT.
"вложенность других шаблонов, условия" - это тоже юзается, при необходимости.

Crazy · 11 Янв 2004

Автор оригинала: [DAN]
Я предпочитаю использовать XML+XSLT.
Классы моделий нагенерили данных, классы представлений отдали шаблоны для этих данных, контроллер всё собрал воедино и отдал пользователю.

Как ты реализуешь запрос данных по инициативе шаблона?

[DAN] · 11 Янв 2004

Автор оригинала: Crazy
Как ты реализуешь запрос данных по инициативе шаблона?

Я не реализую MVC, как таковой, но нечто близкое к нему. Все запросы идут через "главный контроллер", который (в соответствии с конфигом) инициализирует требуемые классы "моделей" и собирает от них данные.

Макс · 11 Янв 2004

Фанат

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

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

PHP:

<? if ($row['email']) { ?> 
          <td class="menu_a" nowrap> 
            <a href="mailto:<? echo $row['email'] ?>"> 
              <img src="/images/mail.gif" width="25" height="10" alt="написать письмо" border="0"> 
            </a> 
            <img src="/images/zero.gif" width="10" height="10" border="0"> 
          </td> 
  <? } else { ?> 
          <td><img src="/images/zero.gif" width="1" height="10" border="0"></td> 
  <? } ?>

у меня реализуется

Код:

<!-- BEGIN row --> 
          <td class="menu_a" nowrap> 
            <a href="mailto:{email}"> 
              <img src="/images/mail.gif" width="25" height="10" 
alt="написать письмо" border="0"> 
            </a> 
            <img src="/images/zero.gif" width="10" height="10" border="0"> 
          </td> 
  <!-- END row --> 
  <!-- BEGIN no_row -->
          <td><img src="/images/zero.gif" width="1" height="10" border="0"></td> 
  <!-- END no_row -->

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

Концепции шаблонов: 2 подхода

/dev/null

Старожил PHPClub

Старожил PHPClub

/dev/null

/dev/null

тинки-винки

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

мизантроп (Старожил PHPClub)

oncle terrible

/dev/null

oncle terrible

/dev/null

oncle terrible

oncle terrible

Demiurg

Guest

Новичок

Старожил PHPClub

Developer

Старожил PHPClub

Старожил PHPClub