Для чего мы делаем шаблоны?

[Фанат]

Для чего мы делаем шаблоны?

С самым сложным вопросом - для кого мы делаем шаблоны - разобрались.
Остался самый простой. А для чего вообще они нужны?
99% пэхапе программистов ответит, что для того, чтобы html не было пхп кода.

Мы с вами уже грамотные, и знаем, что
во-первых, вместо пхп кода напихаем кода на другом языке, например смарти или xslt - и ничего принципиально не изменится. просто поменяли шило на мыло. А можно и пхп оставить, но шаблоны юзать - только в путь.
во-вторых, сама по себе фраза бессмысленная. ну разделили html и php. А ЗАЧЕМ? классический ответ на этот вопрос - "несчастный дизайнер не понимает пэхапе" уже не канает - мы выяснили, что шаблоны делаем для себя. а "дизайнеру" в любом случае придется какой-то язык учить.

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

Теория тоже приветствуется, но только не в виде воды.

 

[AmdY]

Где-то видел статью "Легкая смена дизайна"
Если бы не приходилось менять оформление, особой нужды е было бы. Мне довелось видеть шаблоны в которые вставляются целые таблицы сгенеренные в рнр, если их небыло нужды менять, я оставлял всё как есть. Тот же пиаровский пейджер генерит html в скрипте, но все им поьзуются и не фыркают.

 

[zerkms]

[off]
уже в предвкушении тем:
"чем мы делаем шаблоны?"
"что мы ещё любим делать, кроме как шаблоны?"
[/off]
)))

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

боянная уже фраза: разделение бизнес-логики и логики отображения. если мне нужно исправить ошибку в вёрстке - я иду в шаблон, и правлю 10 строк шаблона, если ошибку в логике - то иду править контроллер, и правлю 10 строк кода
другими словами - меня не отвлекает несущественная в данном случае информация
подытоживая - шаблоны я юзаю, чтобы обеспечить для себя комфортные условия работы (оговорка: комфортные для меня != комфортные для любого другого программиста)

-~{}~ 29.10.07 10:21:

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

 

[jonjonson]

Для чего мы делаем шаблоны?

Что бы более эффективно править код. Программирование - это написание нового, но в большей мере правка старого кода (в конце концов новый код должен интегрироваться в уже написанный). Не важно это html, css, php, javascript. Главное в том, что смешанный код читается и правиться хуже. А если перемешать ещё бизнес логику и логику представления... В общем, разделяй и властвуй.

 

[Духовность™]

просто поменяли шило на мыло.

неужто до этого наконец-то дошли??? медведь в лесу сдох походу...

 

[syfisher]

Какие причины делать шаблоны я вижу:

1) Разделение труда
- Верстальщик не лезет в программный код (пусть это называется контроллер)
- Я не лезу в оформление (что можно назвать отображение).

Причем php-код в оформлении - это нормально до определенных границ (обычно этот код связан с pull-data).

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

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

3) Упрощаем понимание логики отображения.

Здесь есть как бы под-вопрос "Какие шаблоны мы пишем?".

Поясню:

Шаблоны с декларативной разметкой, например,

<pager items_per_page=10>
  <pager:first><a href="{$url}">Первая</a></pager:first>
  [...]
<pager>

читаются, как правило, легче, чем с императивной, и цена их поддержки и изменения меньше (ИМХО).

....
Пока все, что пришло в голову...

 

[atv]

Как продолжение для

1) Разделение труда

На этапе, когда разработан интерфейс пользователя, уже известно, какие данные будут находиться на странице, какие из них будут динамические, какие статические. Соответственно, при использовании технологии XSLT (только не надо истерики , дочитайте до конца), уже на этом этапе можно составить XML документ который должен получиться на выходе приложения и на входе XSLT шаблонизатора. Это значит, что с этого момента программист и верстальщик могут работать ПАРАЛЛЕЛЬНО, а XML документ представляет собой ИНТЕРФЕЙС между приложением и шаблонизатором.

XML документ составляется на основе динамических данных, которые должны быть выданы приложением, статические данные и вёрстка помещаются в XSL шаблон.

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

Шаблонизатор - это ещё одна абстракция, которая позволяет упростить разработку и сопровождение приложения. А вот конкретный эффект от использования шаблонизатора сильно зависит от конкретной реализации.

 

[jonjonson]

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

 

[camka]

Я полагаю, под php шаблонами подразумевается следующий код

=== action.php ===
$a = get_data_from_db();

=== view.php ===
<html><body>
<? foreach($a as $aa): ?>
<li><?= $aa =?>
<? endforeach; ?>
</body></html>

, а не что-то типа такого.

=== index.php ===
show_header();

while(($row = $db->fetch())) {
echo '<li>', $row['zzz'];
}

add_this($fff);
do_that($kkk);

show_footer();

, то есть бизнес-логика не смешивается с логикой отображения. Техника та же, что и в любом шаблонизаторе.

 

[jonjonson]

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

 

[Toxic_Cat]

А для чего вообще они нужны?
Я вижу огромные плюсы использования шаблонов (а именно разделения PHP от HTML).

+ "Переносимость" кода с одного проекта на другой будет равнятся нулю. Так как четкого разделения не будет, а править горы HTML'я мало кому понравится.
+ Мультишаблонные системы в таком случае как будут реализовываться? Если весь HTML код внутри PHP - ужасный гемор с кучей условий.
+ Отделение логики/кода от представления/вывода. Не будет проблем с Куками, Хэдэрами.

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

Все это ИМХО, вообще тема интересная.

 

[Major]

Я вижу огромные плюсы использования шаблонов (а именно разделения PHP от HTML).

??? уже перемывалось тысячи раз. Причем тут отделение пхп кода от хтмл? Чтобы из винегрета хтмл+пхп сделать финигрет с чем-то похожим на пхп +хтмл?


З.Ы.: 2007год, я так понял, год шаблонизаторов, шаблонщиков и прочих тредов на эту тему. Вам не надоело, господа? =) Такое ощущение, смотришь мегасериал. Не, не то сравнение. Как-будто на заседании правительства. Не поняли в 1м чтении, попытаемся во 2м. А во 2м не договорились, давайте на 3е перенесем.

З.З.Ы.: З.З.Ы.: Тока не сильно кричите на меня =)

 

[das6745]

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

1. нужно ли применять поголовно шаблоны? разве никак нельзя обойтиль XML + XSLT? помоему мощности XML должно хватить для любых задач. я для которых нехватит - там врядли какой шаблонизатор поможет (имхо).

2. php вроде как и сам является неплохим шаблонизатором, а оформление кода иметодом "вот тут табличка, тут див а тут foreach а див закрывается в другом файле который подключается через-колено-инклуд" является уникальным говнокодом. я пытаюсь написать небольшой энжайн и использую для оформления класс Web со статик методами, думаю это вполне может попасть под описание шаблонов, или нет? Везде где мне необходимо вывести какие-либо данные я вызываю метод Web'a, передаю ему данные и он сам метод занимается выводом и оформлением, и только им, никакого контроля, никаких ветвлений. только вывод и оформление. Возможно это убогая реалиизация, покритикуйте, буду только благодарен.

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

4. мне кажется, с таким же успехом можно написать php на php

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

 

[Духовность™]

ИМХО, шаблоны нужны. И XXX технологии, и PHP-Pure, и метод а-ля php-BB - все имеют права на жизнь. Не имеет на жизнь метод, при котором HTML-верстку пишут внутри программы.

 

[camka]

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

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

 

[Духовность™]

camka
вот тут, внизу страницы http://phpclub.ru/paste/index.php?show=1915 на твой взгляд хороший пример шаблона?

 

[camka]

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

 

[fixxxer]

'header' => 'Изменения успешно сохранены',
'message' => 'Данные администратора
<strong>'.$out->format($_POST['admin_name'], 'hsc').'</strong> успешно
изменены.<br />Переадресация на модуль «<a href="{url}">управления
администраторами</a>» произойдет через несколько секунд.',
'time' => $_CONFIG['REDIRECT_MAX_TIME'],
'url' => $_HTML['self_uri'].'?action=admins',

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

 

[Alexandre]

Тот же пиаровский пейджер генерит html в скрипте, но все им поьзуются и не фыркают.

не говори за всех

во-первых, вместо пхп кода напихаем кода на другом языке

+1
шаблонизатор должен быть как можно проще.
я считаю, что native-php вполне юзабилити, если правильно им пользоваться.

<html><code><?=$name?></code></html>

мало отличается от

<html><code>{$name}</code></html>

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

несчастный дизайнер не понимает пэхапе

как правило большинство верстальщиков понимают и пхп и "язык шаблонизации". Я еще ни обного верстальщика не встречал, который не понимал бы языки шаблонизации.
Наиболее вероятный ответ - Шаблоны нужны, чтоб представить модель в классическом варианте MVC.
Хотя, если грамотно организовать архитектуру своего приложения и в папку templates положить [code #1] - то такой подход мало отличается от варианта MVC.

-~{}~ 29.10.07 19:31:

1. нужно ли применять поголовно шаблоны? разве никак нельзя обойтиль XML + XSLT? помоему мощности XML должно хватить для любых задач. я для которых нехватит - там врядли какой шаблонизатор поможет (имхо).

das6745 ты здесь не прав. XML + XSLT покрывает большинство задач шаблонизации, но значительно хромает производительность. Можно прикрутить кеширование, но опять же но не для всех задач. Вот по этому и пишутся "шустрые" шаблонизаторы, аля php_templates, blitz, ctpp.

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

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

     <html><code><?=$name?></code></html>

теги <code> на набор тегов <иной code> ?

+ Мультишаблонные системы в таком случае как будут реализовываться? Если весь HTML код внутри PHP - ужасный гемор с кучей условий.

если все организовано в стиле "лапша", то это действительно гемор. Мы в проекте в стиле native за три дня сменили полностью весь дизайн. Не думаю, чтоб это заняло меньше если бы был выбран стиль смарти. C мультишаблонами нет ни каких проблем. меняем require_once ( "test.html.php"); на require_once ( "test.wap.php"); и дело в шляпе!!! Проблема в чем?

+ Отделение логики/кода от представления/вывода. Не будет проблем с Куками, Хэдэрами.

что тебе мешает ее отделять в стиле native-рнр? А причем здесь куки??? и какой может быть гемор Хеадором?
В нормальных стилях шаблонизации использование хедеров и футеров - это порочная практика. Должен быть единый шаблонный макет в который вставляется конкретный контент ( или контентный шаблон с данными). А не отдельный контентный шаблон с хедером и футером!!!

 

[camka]

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

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