FishHookПрограмёр,
так ты же сейчас делаешь сверхошибку! Ты в коде контроллера захардкодил css-классы! Это же жесть как она есть!
ПрограмёрБерём один из общепринятых паттернов - MVC
Какой MVC, как ты можешь говорить про MVC и при этом делать вот так


Ты пойми, разметкой и кодом вообще должны заниматься разные люди, именно для этого и придуман MVC - для разделения ответственности, а у тебя представление размазано по файлам как манная каша по морде, в одной куче всё: пхп, css, html плавно друг-друга обтекают. Это даже не индусский код, это хуже.

Я отдал не css класс. Я отдал тип объекта (просто исторически сложилось, что он одноимённый с css классом :) ). Я же не отдал тэги... или цвет строки!

По какому принципу каждая пятая строка должна быть другого цвета? Если из-за особенности объекта - тогда пожалуйста... готово.
Если из-за того, что это красиво - тогда css в помощь.

P.S. Наверное ты прав. Не могу придумать, как раньше можно было обойтись для таких ситуаций без усложнения синтаксиса того, что я написал. Но это ведь недостаток css. А реализация этого на серверном языке - это костыль.
Теперь же этот недостаток устранили. Потому как минимум сейчас смарти, со всеми его синтаксическими сложностями, стал не востребован.

как то так...Так то да! Контроллер данные отдал. А как вы там разукрашивать будете это его не волнует!;)
Неет... совсем не так (и кстати теоретически может быть ответом на письмо FishHook).
Тот кто отдал данные, и ему всё-ровно что с ними будут делать дальше - это модель :) Она то и отвечает за данные.
А вот контроллер как-раз отвечает за конвертацию данных на пути модель<-->представление. Потому ему то совсем не всё-ровно: в каком виде у него данные запросили, в таком он их и отдаст. А запросили у него их с припиской "и каждую пятую строку выдели мне по-особенному, пожалуйста".

При наличии смарти, паттерн приобретает вид MVCC. То есть модель-контроллер-контроллер(преоразование смарти)-представление.
Тогда давайте избавляться от одного из контроллеров. От основного? Смарти выполнение его задачи не потянет. Потому предложение избавиться от смарти ;)

FishHookПрограмёр, для себя я выработал одно правило, которого всегда придерживаюсь: программу нужно писать так, чтобы при изменении ТЗ править код в одном месте. Если изменения касаются внешнего вида, то правиться должен только шаблон или клиентский код, если изменения в бизнес-логике, то шаблон мы трогать в идеале не должны. Не всегда на практике получается стопроцентно следовать этому правилу, но тем не менее.

Такой подход имеет право на жизнь, и я разумеется тоже придерживаюсь приблизительно тех же правил. Однако, как обычно, есть одно НО...

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

Будет ли нормально, если верстальщик начнёт дёргать программиста со словами "слушай, а как мне определить, есть ли на товар скидка"? А потом после кучи матов со стороны программера, наворотит условий в шаблоне?

А теперь представь, заказчик говорит "я передумал, пускай все весенние товары будут зелёными, а выделение скидок убирайте". Кто это делать должен? Верстак? Да он понятия не имеет что такое "весенний товар". Снова звонок другу (программисту)? Снова куча матов и "как это? а почему так?" ? И снова условия в шаблоне?

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

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

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

P.S. Вот конечно галстук сожрать как некоторый известный всем человек, я не готов, даже если окажется что ошибся

FishHookИзопропилпропущено...

определять принадлежность он же будет?
конечно, а что там сложного то?

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

Итак, вот сейчас ты верстальщик в проекте, не имеющий понятия о том, как работает система в целом. С чего ты начнёшь выполнение данной задачи? :)

P.S. Аналогия :)
есть 4 варианта реализации задачи "прикрутить патрон к проводам нестандартных цветов" (именно таковой и является задача верстальщика почти в любом проекте) :
1. Позвать электрика, что бы он сам подключил (стоит денег)
2. Позвонить электрику, и попросить его рассказать что надо сделать (денег не стоит, но после 5 лампочек перестанут отвечать на звонки )
3. Полезть разбираться в проводке в щиток, и при недостаточных знания дела, стать самому хорошей заменой лампочке
4. Если электрик разводя провода по нестандартной схеме, повесил на каждый соответствующую бумажку со знаками "+", "-", "↓". То я смогу прикрутить патрон сам, без чьей либо помощи (если конечно знаю, что есть "+", "-" и заземление, однако это уже азы, соответствующие некоторой договорённости. Ведь лично для меня он мог повесить другие, если знал, что я пойму).

FishHookПрограмёрпропущено...


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

Итак, вот сейчас ты верстальщик в проекте, не имеющий понятия о том, как работает система в целом. С чего ты начнёшь выполнение данной задачи? :)
Посмотрю в дебагере, что мне пихают в контекст и пойду читать доку по целевому классу. А как иначе то?

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

То есть в дебагере тебе даже смотреть нету на что :)... даже такого массива, как показал Изопропил там нету.

FishHookПрограмёрИзопропил ответил более чем исчерпывающе. Однако добавлю, что ранее у программиста не было задачи выводить какие-то дополнительные данные тебе в представление (а возможно таких данных в прямом виде вовсе нету в системе, и для их получения надо лезть в контроллеры, а то и в модели, и самому добавлять нужные методы, что бы получить нужные данные в таком виде).

То есть в дебагере тебе даже смотреть нету на что :)... даже такого массива, как показал Изопропил там нету.

Обычно, программист не делает отсебятину, а пишет классы в соответсвии с интерфейсом, разработанным архитектором проекта. Как правило, в конторе формат данных, передаваемых в контекст шаблона и/или REST-resoponse стандартизируется и вопросов не возникает.

Задача: Есть таблица товаров. Каждый товар входит в некую группу. Надо вывести особым цветом товары, с максимальной популярностью в группе, а в последней колонке вывести название этой группы. В шаблон тебе поступают данные:



Итак, ты верстак, и знаешь азы программирования (циклы, условия, использование переменных, арифметические операции). Выполни задачу, оставив сам шаблон в нормальном, читабельном виде. Ах да... ни разу не обратившись за помощью к квалифицированному программисту :)

Вот я задачку написал... сижу оцениваю, сколько бы я потратил бы на решение задачи.
По моему мнению от 30 минут до часа... Написав предела 20 строк кода.

Думаю верстальщик потратил бы день минимум. Только у него в шаблоне нету возможности писать 20 строк кода :) Иначе шаблон превратится в кашу из вёрстки и логики. Потому на его уровне, по моему, задача не решаема.

Можешь ли ты доказать обратное? :)

как то так...fishhook прав на сто процентов! Здесь и сейчас можно убиться в оч раз доказывая обратное... тот контроллер который подрисовывает что то для разметки становиться постепенно ТТУК!
Контроллер всего лишь клей между моделью и представлением... не более!
Представь себе сервис который отдает тебе данные... как и в каком порядке их расставлять решать тебе... это и есть представление!
Уже говорено переговорено на эту тему!

Да нет же )))) Порядок определяется контроллером. Особенности вывода определяются контроллером. Формат данных определяется контроллером!!!

Представлением определяется только внешний вид данных.

Возвращаясь к последней задаче: Вывести товары в порядке спадания популярности! Как в представлении решить задачу?! (хотя для программиста в контроллере она мега простая).