@Yakud в непонятных ситуациях я часто прибегаю к рассмотрению предельных случаев, чтобы прочистить голову.
Такой шаблонизатор, конечно, не нужен, но хорошо показывает, как оно по идее должно работать в некотором сферическом мире в вакууме.
Ваш пример с массивами/объектами не очень хороший, поскольку путем несложных телодвижений можно приделать доступ к объекту как у массиву ($myObject['prop1']). Тут вопрос скорее в том, собираетесь ли Вы вызывать какие-то конкретные методы объекта, и что это за методы. Понятно, что геттер-метод и метод, вызывающий модификацию данных объекта - это совсем-совсем идеологически разные сущности.
Про верность подхода... ну, от ситуации зависит, конечно. Простой пример: допустим, в контроллере вы каким-то образом добыли некий список объектов, а в представлении вам железно нужен массив. Идеологически верным (если забыть про arrayable interface) в это ситуации, полагаю, является предварительное преобразование списка в нужный формат на стороне контроллера. Но теперь предположим, что единственное, что происходит в представлении - вывод списка элементов в виде таблицы. Иными словами - for-цикл. И вот в этот момент в голове появляется нехороший червячок, шепчущий: "лишний цикл, убери лишний цикл...". Как бороться с червячком, и надо ли бороться вообще - от Вас зависит.
Идеальный сферический конь, про которого я всегда люблю вспоминать в таких случаях - XSLT-преобразование. Вроде бы все офигенно: формируем xml, передаем, а дальше хоть в браузере рендерить можно, хоть на сервере. Данные как на ладони, вызов критичных методов невозможен, и вроде всё здорово. Но потом оказывается, что на клиенте рендерить xslt - зло, а на сервере - немного нелепо (добыли данные, обернули в xml, преобразовали xslt, отдали... а сразу отрендерить нельзя было?..)
Много букв, да. Сам вот хожу постоянно и мучаюсь вопросами "а как правильно-то?". И хоть бы одна сволочь ответ дала :)
@TsarS к счастью, обновление не настолько серьезное :) (не с 5.2 на 5.5, а с 5.4.x на 5.4.y) Это не вызывает проблем, но даже такой фигни от хостеров не допросишься.
@WaRstim а, понял. Ну у Вас там сейчай идет суммирование по всем товарам за конкретный год (условие в WHERE).
Если я правильно понимаю, нужно за несколько лет извлечь.
Замените условие на что-нибудь типа WHERE дата IN (список дат) и добавьте группировку по дате
@nepster09 конкретно по этому вопросу - достаточно в JS-коде переопределить yii.allowAction, заменив на свой обработчик. Вот и все шаманство :)
На англофоруме я показывал, как это делается.
Еще часто требуется прицепиться к стандартным хукам activeForm.js, чтобы выполнять свои действия в нужный момент (после клиентской валидации, но до сабмита, к примеру).
Во всех остальных случаях разницы особо никакой нет.
@mkharitonov Ну, они есть, да, но сводятся к подключению необходимых файлов (js, css) и навешиванию обработчиков (к примеру, onclick). Но, во-первых, делают это достаточно сомнительным образом (js-код в php-коде), во-вторых - не делают ничего такого, что не умеет обычный рукописный код прямо в шаблоне.
Конкретную задачу про голосование я вообще не понял, поскольку у пользователя ВООБЩЕ не должна отображаться активная кнопка голосовалки с случае наличия информации о том, что он уже голосовал.
Если же взять какой-то другой абстрактный пример (при нажатии кнопки что-то происходит на клиентской стороне) - ну, тут все просто: можно использовать стандартный хелпер для вывода элемента с навешенной логикой. К примеру, ссылка, при нажатии на которую происходит post-запрос, вернувшийся результат изучается и в зависимости от того, что произошло - вызываем либо показ модального окна, либо что-то еще.
Иными словами, можно разрулить на стандартных хелперах/виджетах, да. Но сначала - подумать, стоит ли так делать.
