Ужас. Это грубое нарушение принципов MVC. Что Вам помешало не допустить этого?
это часть шаблона, логики шаблона
Логика шаблона это когда исполняются некоторые действия исключительно вьюшные. В оформительских целях (зебра) или для поддержки HTML (из массива сделать набор <option>ов). То есть шаблон вообще не в курсе, что он рисует и к какой отрасли знаний это отоносится. А вот когда в логике шаблона начинают участвовать некоторые понятия из бизнес логики (отрицательная сумма -> бухгалтерия), то это уже не "логики шаблона", а то самое нарушение MVC.
бред. чем рисование отрицательных сумм красным отличается от зёбры?
Это можно сделать так (с ЧПУ).
<?php
return array(
//...
//таблица начальной маршрутизации
//в ключах шаблоны запроса (URL), а в значениях запускаемый шаблон относительно папки "/templates"
//для URL точное соответствие [O(1)], шаблон поиска (wildcard/fnmatch) или рег. выражение (PCRE) [O(n)] определяется автоматически
'route' => array(
//страницы веб-сайта (по-умолчанию)
'http://domain.com/*' => 'default/main.tpl.php',
//админка
'http://admin.domain.com/*' => 'adm/main.tpl.php',
/*CSS
* На prod-сервере: рекурсивная замена инструкций @import "*.css" на содержимое файлов (с проверкой на однократное включение), оптимизация (исключая *.min.css) и сжатие;
результат кладётся в styles.css и styles.css.gz (это делается только один раз при первом запросе, за это отвечает Nginx)
* На dev-сервере: вывод шаблона без изменений, с сохранением инструкций @import "*.css", чтобы было удобно отлаживать в браузере.
*/
'http://static.domain.com/css/styles.css' => 'js/main.tpl.php',
/*JS
* На prod-сервере: рекурсивная замена инструкций require('*.js') на содержимое файлов (с проверкой на однократное включение), оптимизация (исключая *.min.js) и сжатие;
результат кладётся в main.js и main.js.gz (это делается только один раз при первом запросе, за это отвечает Nginx)
* На dev-сервере: рекурсивная замена инструкций require('*.js') на содержимое файлов (с проверкой на однократное включение)
*/
'http://static.domain.com/js/main.js' => 'css/main.tpl.php',
//рекламные спецпроеты, для http://www.domain.com/* сделано перенаправление на http://domain.com/* в Nginx
'~http://([-_a-z\d]+)\.domain\.com/*~siSX' => 'special/$1.tpl.php',
),
);Тем, что бизнес логика, оказывается в шаблоне. Пример с "красным" возможно не самый удачный (поскольку понятие "красного" является уже достаточно общим, не исключительно бухгалтерским), но тенденцию по нему увидеть все же можно -- шаблон анализирует величину проводки и принимает некоторые решения с этим связанные. Если ты не видишь тут функциональности, которая по идее должна находиться в модели, то извини, пусть будет бред.
С., я не претендую на истину, но тоже согласен с Духовность™ что это дело шаблона. Да это логика, но больше логика визуализации чем бизнес правило, по-этому (имхо) уместней её пихать в шаблон.
Логика визуализации не оговаривается в ТЗ. Ни один клиент не будет диктовать в ТЗ какого цвета полосы у зебры и с какой начинать. Это чистый дизайн. Но если в ТЗ, говорится, что у отрицательных суммы убиратеся минус и они выдаютя красным, то это бизнес логика. Заметьте не оговаривается RGB цвета, а вводится такой БИЗНЕС-термин "красное". Он может быть в дизайне на самом деле малиновым, оранжевым или розовым. Если быть совершенно корректным, то надо в шаблон выдавать число и признак "красности". Естественно этим мало кто будет заниматься, гораздо ведь проще проверку в шаблоне сделать.
В каждом случае очень тонкая грань куда подобную логику относить, но если она нужна только для во view, то я действительно делаю template helper и не заморачиваюсь, если иногда (даже хоть раз) нужно использовать в контроллере/моделях - то делаю методом модели.
Какая каша..
Расскажите лучше, куда запихиваете обновление данных. Тоже из view вызываете сохранение моделей?