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

Фанат

oncle terrible
Команда форума
Для кого мы делаем шаблоны?

Много было копий сломано на тему, какой шаблонизатор лучше.

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

Эти два конкурента - антагонисты по определению.
Если создатель шаблона имеет полную свободу самовыражения (захотел - в три колонки сделал, захотел - в одну. пожелал вывести полные тексты новостей, а не пожелал - только заголовки и первые сто слов текста, и т.д.), то очевидно, что ему нужны МОЩНЫЕ средства для такого самовыражения.
Если же создатель шаблона знает только HTML, то ему нужен язык шаблонизации как можно более простой. правда, платой за это становится работа в паре с программистом - верстальщик помечает в шаблоне "вот здесь будем в цикле новости выводить", а программист потом пишет программку, которая эти новости выводит.

Ярким представителем первого подхода является связка XML+XSLT. Олицетворение идеологии. Есть набор данных и есть программа, которая занимается их отображением. создатель шаблона - это такой же программист однозначно.
Для второго подхода я затрудняюсь назвать такого яркого представителя, но пусть это будет xTPL, поскольку я уже использовал его в своих предыдущих исследованиях на ту же тему. Теоретически, создатель шаблона может быть любым человеком, и менять шаблон, но только в рамках того, что ему дал программист.
так же примером такого подхода является применяемы лично мной strictly limited php native, когда из операторов мы имеем только echo, if и foreach

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

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

cDLEON

Онанист РНРСlub
но пусть это будет xTPL
Пиар ? =)
А по теме... Есть у меня один знакомый дизайнер. Не знает не только смарти, но и ХТМЛ толком. Но дизайн свёрстаный умудряется в смарти запихнуть =)) И говорит, что смарти ему нравится тем, что весь шаблон лежит в одном файле. А фишки всякие, с ф-ями он не знает, и это ему не надо. Т.к. ему только дизайн натянуть нужно.
ПЫСЫ. От идеи компилирования шаблонов тошнит по идеологическим причинам. Собственно поэтому я смарти ни где и не использую =)
 

CatManZero

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

jonjonson

Охренеть
ИМХО 1. Я имею дело как с нетив php шаблонами, так и со Smarty. В начале разделял для себя как программиста. Потом стал работать с дизайнерами и только один из них отказался понимать нетив php. Остальные без всякого роптания работали как с нетив php, так и со Smarty. Задавали вопросы, но работали :)

И ещё тут маленькая не увязка. Есть не только программисты и дизайнеры, но и верстальщики. Что программист, что дизайнер могут совмещать эту должность. А она в любом случае подразумевает понимание программного кода. Ни кто же не отрицает, что программист должен знать xhtml и сss. Другое дело, что он с применением этих знаний должен делать и что не должен.

~ Обновлено, так как автор поменял нумерацию тоже :)
 

Фанат

oncle terrible
Команда форума
php может представлять собой как первый вариант, так и второй.
strictly limited php native, когда из операторов мы имеем только echo, if и foreach - это, практически, второй вариант.
Ну, а когда применение пхп ограничено только фантазией разработчика - то первый.
 

ran

Новичок
выбираю первый вариант, потому что дизайнер пускай рисует и не тратит свое время на освоение премудростей верстания и шаблонизатора, если ему это неинтересно.
верстальщик если не знает программирования, то
помечает в шаблоне "вот здесь будем в цикле новости выводить"
от связки XML+XSLT почему-то воротит и нет желания пользоваться, а вот принцип построения смарти-шаблонов (пробовал также quicky) пришелся по душе.
P.S. идеала в шаблонизаторах не ищу, потому что его нет и не будет, выбираю только исходя из субъективных оценок: какой удобнее использовать в конкретном случае, после смотрю на производительность и по этим двум показателям выбираю.
 

fixxxer

К.О.
Партнер клуба
а вот у меня есть идея органичного совмещения п.1 и п.2, но я вам ничего не скажу пока;)
 

ustas

Элекомист №1
fixxxer
партизан типа

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

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

akd

dive now, work later
Команда форума
свои "мегапроекты" пишу с strictly native, по работе - XML/XSLT.
 

Духовность™

Продвинутый новичок
Небольшое отступление:

Я работал во многих компаниях, нигде почти не встречался с шаблонизацией. Максимум, что было - Смарти - в Бегуне, но оттуда я ушёл быстро, не захотел там работать...

Native PHP, когда в шаблоне
только echo, if и foreach
- писал только я, ибо в остальных случаях всегда была аццкая смесь PHP и html. Сайт superjob.ru, например, популярный портал по поиску работы - аццкая смесь такого вот решения. Кривейший код, при этом ребята откровенно считают себя лучшими.

К чем я? Да к тому, что xslt всякие применяют очень мало. Смарти и php native - те, кто как-то пытается отделить одно от другого. В остальных 99% случаев контент (HTML и данные) складывается в переменную $TEXT и выводится где-то в body.

Вот и сейчас занимаюсь этим (
 

HraKK

Мудак
Команда форума
Все останутся при своем видиньи, я предлагаю - два шаблонизатора для тех кому надо 1 или 2 подход.

А я использую тот который Мне больше нравится. А "дизайнеров" я либо научу либо уволю)
 

atv

Новичок
Может лучше самих дизайнеров спросить, или верстальщиков?...

А по поводу XSLT, так это не первый вариант. Это "язык предметной области" описанный в статье Фаулера http://www.maxkir.com/sd/languageWorkbenches.html, со всеми вытекающими...
 

Wicked

Новичок
У меня несколько ситуаций одновременно:

1) Старые проекты делались на движке типа смарти. Дизайнеры-верстальщики темплэйты не делали. Они только делали картинки и статичный html, которые уже прикручивались программистами.

2) Новый мой проект. На 95% сделан с использованием ajax, соотв-но темплэйтов почти нет - одна статика.

3) Когда делаю что-то для себя, использую symfony + native php. Темплэйты, соотв-но, тоже делаю сам.
 

Bermuda

Новичок
2007-й год на дворе, а народ все еще html-шаблонами балуется.
Кроме шаблонов еще есть такое понятие как controls (компоненты).

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

Плюсы подхода:

- Пространство html расширяется за счет создания новых классов компонентов. Посмотрите на операционную систему. Сколько в ней компонентов, а сколько из них нам доступно в html? Какие извраты приходится делать каждый раз для имитации недостающих компонентов!

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

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

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

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

А уж будет ли в шаблоне {FOO} или <?php $foo->render(); ?> дизайнеру обычно по барабану.
 

Фанат

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

спасибо за ваш голос в пользу второго варианта
 

atv

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

Верстальщик создаёт каркас HTML страницы в шаблоне <xsl:template match="/">, и в нём указывает "что вот здесь будем выводить элемент news" <xsl:apply-templates select="news"/>, причём его даже не интересует в цикле или ещё как.

Ведь абстракция xsl:template используется для описания сущностей находящихся на различных уровнях приложения. xsl:template с параметром match="/" относиться к уровню приложения, т.е. специфичному для каждого приложения, в нём строится общий каркас страницы. В Symfony для этого уровня предназначен layout.

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

StUV

Rotaredom
+1 за 1
"современный верстальщик" в своей работе сталкивается с такими конструкциями, что изучить синтаксис любого шаблонизатора, включая strict-php, для него только вопрос времени
 

CatManZero

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

fisher

накатила суть
а я вот не вижу никакой разницы между 1 и 2 в той формулировке что предложена в первом посте. давайте взглянем на роли. первая роль- HTML-человек. он делает правильный HTML, плюс да яваскрипт. щас на клиенте довольно замороченный код почти у всех крупных ресурсов. программист как правило такой работы бежит. прекрасно. что надо дать этой роли? возожность поменять что угодно в области его отвественности - то есть в HTML или JS и что там ещё. но не логику вывода. вернее не ту логику где какие-то данные из программы передаются и вставляются в его HTML. потому что это уже логика, и она у программиста. и это вторая роль. итого: где HTML - там попроще, но в целом вполне себе MVC. в чём проблема-то?
 
Сверху