Да ладно, Алексей. Смесь с тем же успехом станет ещё запутаннее в шаблоне с блоками (с-ничего-не-говорящими-через-пару-месяцев названиями блоков — что ещё хуже) и в управляющем этим шаблоном коде; и когда в смеси пхп+хтмл можно обойтись одним ифом, то в том же blitz придется нарисовать блок в шаблоне и добавить тот же иф в управляющий код.
И я говорю не о «производительности», а о том, чтобы иллюзий не питать о возможности разделять и властвовать используя шаблонизатор. Сложность будет нарастать в любом случае — с шаблонизатором или без него. Другое дело, что сложность смеси пхп+хтмл ниже сложности смеси пхп+хтмл+логика шаблонизатора.
1. шаблонизатор сам по себе ничего не отделяет. а в случае с блитзом ещё и добавляет дополнительный слой приложения, называемый «контроллер представления» — тем самым увеличивая косты на саппорт.
1. что означает «отделять логику от представления» — логику чего? логику представления от самого представления? Кому проще понимать шаблон? Верстальщику или разработчику? Какая реальная польза от этого? Как это разделение увеличит скорость разработки? Как это разделение упростит поддержку решения? Для того, чтобы вывести дату в другом формате например надо будет внести изменеия в двух файлах?
вот-вот. мы до определённого момента пользовались разделением на шаблон и управляющий код. пересев на зенд_вью мы поняли сколько времени мы просто теряли даром — ведь приходилось работать с двумя файлами и переключаться между ними (пхп и сам шаблон), хотя реально работаешь над _одним_ шаблоном.
а если уж говорить о каких-то банальных легких модификациях одной и той же строки, которую надо передать в шаблон, то это вообще огород — приходилось передавать два значения в шаблон.
Уважаемый автор, что по вашему такое «логика приложения»?
Вот допустим надо вывести в что-то в два столбца в таблице, причем это нельзя сделать «правильным путем» (для сложности примем что ячейки таблицы снабжены разными атрибутами style) — просто размножить одну ячейку не получится.
Логика, которая будет рубить набор элементов на две части а затем засовывать получившееся в две ячейки — это логика приложения или логика отображения?
Другой вопрос: Если рассматривать MVC, то где предполагается держать вот этот например код:
И я говорю не о «производительности», а о том, чтобы иллюзий не питать о возможности разделять и властвовать используя шаблонизатор. Сложность будет нарастать в любом случае — с шаблонизатором или без него. Другое дело, что сложность смеси пхп+хтмл ниже сложности смеси пхп+хтмл+логика шаблонизатора.
hello <?php echo implode(', ', $names)?>
вот например кусок «кода контроллера»
public function rssAction() {
$view = new My_View();
echo $view->render('Rss.phtml');
}
я считаю, что это идеальный подход и больше ничего в контроллере быть не должно чтобы показать rss.
пусть вьюха сама всё дёргает из базы.
логика приложения это: «показать юзеру набор результатов»
логика представления это: «как именно показать, в каком формате и тд и тп»
согласны?
а если уж говорить о каких-то банальных легких модификациях одной и той же строки, которую надо передать в шаблон, то это вообще огород — приходилось передавать два значения в шаблон.
Вот допустим надо вывести в что-то в два столбца в таблице, причем это нельзя сделать «правильным путем» (для сложности примем что ячейки таблицы снабжены разными атрибутами style) — просто размножить одну ячейку не получится.
Логика, которая будет рубить набор элементов на две части а затем засовывать получившееся в две ячейки — это логика приложения или логика отображения?
Другой вопрос: Если рассматривать MVC, то где предполагается держать вот этот например код:
$data = array(
0 => array(
'block' => array(
0 => array('name' => 'Dude'),
1 => array('name' => 'Sobchak'),
2 => array('name' => 'Donny')
)
),
);
$template = new Blitz('some.tpl');
echo $template->parse($data);
?
В контроллере или во вьюхе?
самое интересное в альфе, что на любую внешнюю транзакцию вы тоже получаете код смской!