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

Статус
В этой теме нельзя размещать новые ответы.

Фанат

oncle terrible
Команда форума
syfisher
Разделение труда не является основной причиной для использования шаблонов.
В больших проектах вообще используется разделение, и при написании чисто бизнес-логики - тоже.
Мы же говорим об общих принципах. Вот как раз я и хочу полчить ответ на вопрос - почему именно так делят?
И почему все равно используют шаблоны, даже когда разделения никакого нету.
Здесь есть как бы под-вопрос "Какие шаблоны мы пишем?".
НЕТ. Нету здесь такого подвопроса, и я НАСТОЯТЕЛЬНО попрошу не устраивать здесь очередную горлодерню на тему "мы делаем вот так, а все кто делают не так - сосут подпрыгивая".

просьба относится КО ВСЕМ участникам.

-~{}~ 29.10.07 20:46:

atv
про уровни абстракции - хорошй аргумент.
Вот только если объяснять новичку, то слова "всем понятно, а кто не понял - иди Буча почитай" аналогичны, к сожалени., высказыванию "ты лох, и ваще ничего не понимаешь".
А я бы очень хотел избегать таких формулировок.

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

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

das6745

Новичок
Alexandre
во, производительность это да, XSLT немного тормознутое, но, согласитесь, его мощь того стОит, имхо. вообще мое мнение- любой шаблон - это избыточность

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

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

Toxic_Cat

Новичок
Alexandre, я за Native PHP шаблоны (если я правильно понял вообще это определение).

О какой переносимости идет речь? если это типовая витрина типового магазина, и для другого проекта, максимум что нужно - это поменять дизайн? Что тебе мешает сменить в тексте <html><code><?=$name?></code></html> теги <code> на набор тегов <иной code> ?
Немного неправильно высказался.
"Переносимости" не будет если устраивать винигрет без использования шаблонов.

<html><code><?=$name?></code></html>
вот такому шаблону +1 (именно такой шаблон был приведен в примере camka), но только если этот код вынесен вы отдельный файл и подключается после выполнения всего сценария (запросов к БД, обработке данных, проверке переменных).
 

fixxxer

К.О.
Партнер клуба
но в реальности мы ему выдаем лишь кусочек ленты. и где устраивать новостям обрезание до 1000 букв - вопрос!
о, спасибо за хороший пример, у меня вот в голове вертелось, что view это не только "после модели" но и некоторая инициализация "до". :)

-~{}~ 29.10.07 21:56:

и еще к размышлению - URL, как сущность, к какому звену MVC относится?
 

dark-demon

d(^-^)b
> XML + XSLT покрывает большинство задач шаблонизации, но значительно хромает производительность. Можно прикрутить кеширование, но опять же но не для всех задач.

xsl трансформации в большинстве случаев можно возложить на клиента :) я даже статейку небольшую написал :)
 

Фанат

oncle terrible
Команда форума
еще раз прошу прекратить обсуждение достоинств и недостатков различных конкретных шаблонизаторов
 

dark-demon

d(^-^)b
я использую шаблоны, чтобы разгрузить сервер от изнуряющего процесса натягивания шкурки на данные :)
 

Major

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

Я воспринимаю шаблон как некую "шкурку", в которую "впрыскиваем" данные и они ложатся на свои места. Ничего лишнего. Хоть это и логика представления, но она не должна влиять на контроллер. Никаких калбэков. Все что надо, программист определит, а в шаблоне только расстановка того, что было определено.

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

korchasa

LIMB infected
Не хочется говорить за всех, буду говорить за себя:
1. Для отделение модели, от ее представления. В общем случае поведение модели сводится к "если-условие-что-то делаем". Поведение представления "если-условие-показываем что-то". Это позволяет:
  • при правке шаблонов видеть что он должен ПОКАЗЫВАТЬ в зависимости от того, что ему дано;
  • при правке доменнов думать что надо ПЕРЕДАТЬ в шаблон, не заморачиваясь, как там это будет отображаться;
  • запихивать константы, типа текстов и прочего, туда, где они будут отображаться;
  • применять шаблон для разных наборов данных, и наоборот;
  • еще 33 пунтка, которые не лезут сейчас в голову;
2. Ради возможности разделить представление на независимые куски:
  • реюзабельность шаблонов внутри других шаблонов;
  • валидность кеша отдельных кусков представления;
  • уверенность в том, что поправив один шаблон, не придется править остальные 42;
3. Чтобы с малой кровью его поменять :)

Не пинайте "мы все это и так знаем", просто описал для чего он МНЕ.
 

С.

Продвинутый новичок
Часто приходится просто повторять статические куски HTML с небольшими вариациями. Например все картинки на сайте показываются в какой-нибудь художственной рамке или с тенью. Или даже просто плавающуе картинки с caption. Копипейстить строк пять на каждую картинку -- занятие не из приятных. Что-то типа <?ImgShadowed('pic.jpg')?> или <?ImgCapt('pic.jpg','Буш жмет руку Путину')?> -- спасение.

Формально эти вставки не имеют никакого отношения к MVC или подобным парадигмам. Они просто для удобства верстания документа. Но заводить какую новую сущность, отличную от шаблонизатора, для решиния таких вопросов было бы глупо. (Мне кстати стало интересно, как смарти-подобные шаблоны предлагают помощь в таких задачах?)

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

pachanga

Новичок
Автор оригинала: С.
Предлагаю забыть про мифическое отделение кода от HTML и взглянуть на шаблон с другой стороны. А именно рассматривать шаблонизатор чисто как расширение (макро)...
Bingo! ;)
 

jonjonson

Охренеть
рассматривать шаблонизатор чисто как расширение (макро) для работы с HTML.
А если я использую шаблоны для формирования тела письма да ещё без html? (Кстати xml + xslt ограничиваются формированием "теговых" структур?)

ИМХО шаблонизация - это применение трафарета. (Одна из реализаций подхода: разделяй и властвуй.)

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

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

dark-demon

d(^-^)b
> Кстати xml + xslt ограничиваются формированием "теговых" структур?
нет
 

С.

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

Я говорю принципиальном изменении подхода. Само слово "шаблонизатор" уже теряет смысл. Представьте себе Нечто вроде CSS и DHTML на стороне сервера. Не замена клиентского CSS, а в дополнение. Чтобы покрыть функции как шаблонизатора, так и поднять на ступень урoвень абстракции самого HTML, для удобства данного конкретного приложения.

Например "шаблонный" код:
Код:
<img class="caption" src="pic.jpg">
  <b>Буш</b> жмет руку <b>Путину</b>
</img>
Транслируется в:
Код:
<div class="img_caption">
  <img src="pic.jpg">
  <div class="caption">
    <b>Буш</b> жмет руку <b>Путину</b>
  </div>
</div>
 

atv

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

и где устраивать новостям обрезание до 1000 букв - вопрос!
Если следовать компонентной структуре, то это может быть настройкой компонента - обрезать новости или нет, и на сколько.

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

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

asm

Пофигист
1. Что бы код легко читался
2. Быстрая смена дизайна. Хотя в последнее время это не так актуально CSS спасет мир.
3. Такая архитектура приложения MVC способствует быстрому расширению функционала, работы команды разработчиков над одной задачей.
 

pachanga

Новичок
Автор оригинала: С.
Например "шаблонный" код:
Код:
<img class="caption" src="pic.jpg">
  <b>Буш</b> жмет руку <b>Путину</b>
</img>
А какая разница, если он будет записан так:

Код:
{{article:img class="caption" src="pic.jpg"}}
  <b>Буш</b> жмет руку <b>Путину</b>
{{/article:img}}
...и в итоге получится то что ты хочешь?
 

Alexandre

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

Pigmeich

Новичок
С.
Блин, бинго.

Если получиться модуль Server-Side Styles я всё-таки допишу.
И ссылку сюда положу.
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху