Хабр нам всем близок, не считаю зазорным рассказывать о том, на чем он построен.
Сами используем смарти и довольны. Даже уже пробуем 3ую версию.
Но есть у нас и проблема, которая подталкивает к поиску — с ростом функционала шаблоны становятся трудно-поддерживаемыми.
И на смарти все можно красиво организовать и зарефакторить, другое дело, что с Блитц
так просто не получилось бы сделать.
Поэтому в новых разработках, у себя будем пробовать.
К анализу в данный момент я не готов.
Но если интересно сравнить, рекомендую скачать: alexeyrybak.com/blitz/lebowski_bench.tar.gz — там реализован очень простой сайт с использованием всех перечисленных на графике шаблонизаторов.
Да.
По поводу отделения: в Blitz невозможно поместить логику приложения в шаблоне.
Если взять Smarty или PHP, то там в шаблоне можно целю программу написать.
Слой «контроллер представления» уже есть, если вы используете шаблонизатор.
Smarty:
$tpl = new Smarty();
// вот он слой: контроллер представления - это подготовка данных для шаблона
$tpl->assign('var', 'Hello');
$tpl->display('template.tpl');
в случае с Blitz:
$tpl = new Blitz('template.tpl');
//слой: контроллер представления
$data = array('var', 'Hello');
$tpl->parse($data);
В случае с Blitz меньше логики будет в шаблоне, но больше строчек после коммента «слой: контроллер представления».
По первому вопросу, очевидно, логика отображения рубит, а логика приложения поставляет данные на рубку.
По второму: я бы этот код отнес ко View, в некоторых, простых случаях можно и в Controller поместить. Это решение принимает разработчик на свое усмотрение. Шаблонизатор не диктует применение какого-либо паттерна.
Дробим, но получается каталог шаблонов модуля с кучей файлов, до 20 шт.
И при таком кол-ве по названию шаблона не всегда можно догадаться где используется и для чего нужен.
Дока, которую мы используем для документирования php — изобретение команды разработчиков
phpDocumentor, которые скопировали ее из встроенной документации java
А спецификации то нет :)
Если вы считаете, что документация поможет вам работать — почему не принять свой стандарт.
Ps: Не всякой команде и не всякой программе/продукту нужны доки. (не только шаблонные)
Пример: шаблон для вывода постов не предназначен для вывода комментов так как
набор данных передаваемых в посты будет отличаться от данных для вывода комментов.
Сами используем смарти и довольны. Даже уже пробуем 3ую версию.
Но есть у нас и проблема, которая подталкивает к поиску — с ростом функционала шаблоны становятся трудно-поддерживаемыми.
И на смарти все можно красиво организовать и зарефакторить, другое дело, что с Блитц
так просто не получилось бы сделать.
Поэтому в новых разработках, у себя будем пробовать.
К анализу в данный момент я не готов.
Но если интересно сравнить, рекомендую скачать: alexeyrybak.com/blitz/lebowski_bench.tar.gz — там реализован очень простой сайт с использованием всех перечисленных на графике шаблонизаторов.
По поводу отделения: в Blitz невозможно поместить логику приложения в шаблоне.
Если взять Smarty или PHP, то там в шаблоне можно целю программу написать.
Smarty:
$tpl = new Smarty(); // вот он слой: контроллер представления - это подготовка данных для шаблона $tpl->assign('var', 'Hello'); $tpl->display('template.tpl');в случае с Blitz:
$tpl = new Blitz('template.tpl'); //слой: контроллер представления $data = array('var', 'Hello'); $tpl->parse($data);В случае с Blitz меньше логики будет в шаблоне, но больше строчек после коммента «слой: контроллер представления».
По второму: я бы этот код отнес ко View, в некоторых, простых случаях можно и в Controller поместить. Это решение принимает разработчик на свое усмотрение. Шаблонизатор не диктует применение какого-либо паттерна.
Попробовали в одном проекте, скорее всего будем использовать и дальше.
prestashop тоже хочу попробовать
До этого, инструментом планирования (backlog) была электронная таблица в docs.google.com, в роли issue tracker-а была жира.
Пивотал — средство «два в одном» :-) и баг-трэкер и планировать помогает.
Перед использованием, рекомендую почитать о Scrum: habrahabr.ru/blogs/pm/47910/ (книга Scrum и XP: заметки с передовой)
И при таком кол-ве по названию шаблона не всегда можно догадаться где используется и для чего нужен.
Дока, которую мы используем для документирования php — изобретение команды разработчиков
phpDocumentor, которые скопировали ее из встроенной документации java
А спецификации то нет :)
Если вы считаете, что документация поможет вам работать — почему не принять свой стандарт.
Ps: Не всякой команде и не всякой программе/продукту нужны доки. (не только шаблонные)
Пример: шаблон для вывода постов не предназначен для вывода комментов так как
набор данных передаваемых в посты будет отличаться от данных для вывода комментов.
2. И еще не редко бывает — одни разработчики сменяют других.
нетривиальным местам и костылям любой природы.
это то, что мы видим доку непосредственно при работе с кодом.
Вот, посмотрите доку от ZendFramework: framework.zend.com/apidoc/1.10/
Она есть, но гораздо удобнее юзать референс: framework.zend.com/manual/en/
А когда мы работаем с кодом редакторе или ide тут и проявляется сила встроенной документации. :)
Некоторые IDE умеют подсказывать при наличии доков (к сожалению, к шаблонам это пока не относится).
Просто тот факт, что при открытии шаблона сразу видно какие данные туда передаются
уже снимает много вопросов.
Наверное, веб-технологи и верстальщики, те кому приходится много работать с шаблонами, подтвердят мои слова.