itcoder: если правая колонка меняется, ее не должно быть в главном шаблоне. лучше пусть из кусков собирается на каждой странице. либо в правой колонке воткнуть плейсхолдер типа {right_content}, который собирать в другой вьюшке.
у меня контроллеры передают друг другу по цепочке параметры, начиная с корневого, отвечающего за корень (обычно "/") сайта, дополняя по ходу необходимыми для следующего.
itcoder: не понял вопроса. разные страницы - это разные методы же? или в том же методе? чем if/else не устраивает? по каким критериям выбирается какой где блок?
на ваши вопросы больше вопросов, чем ответов ) переформулируйте что-ли...
В моем фреймворке, к примеру, иерархическая структура контроллеров (HMVC), куда виджеты-миниконтроллеры вписываются по определению. Если вам мешают рамки вашего фреймворка, решать вам - либо расширить эти рамки, либо упорно пытаться в них втиснуться.
itcoder: ИМХО, виджет для полноценного функционирования должен выполнять функции контроллера, который отличается от обычных своей самодостаточностью, тем, что не обязательно привязан к конкретному адресу (хотя и может иметь свой - для редактирования/настроек, к примеру), и может быть подключен засчет этого в любом месте.
Понятия не имею что в других фреймворках понимают под виджетом, можете назвать такой контроллер по-другому, если это вызывает у вас непонимание.
зачем? в конструкторе или отдельном методе init() сделайте выборки. опции в конструктор - чисто для настроек типа сколько рядов, в каком виде какого цвета ит.п. зависит от фантазии и требований.
EVOSandru6: (я не против ответить здесь, просто вопросов много, а комментарии не слишком хорошо подходят для того, чтобы все подробно расписывать, да и вопросы уже пошли по другим темам)
65536: согласен, что иногда нужно/удобно получить колонку отдельно или сделать колонку ключами массива, и код по ссылке отлично для этого подходит. однако зачем это было пихать прямо в самодельный "fetch_all"
С рапределенными системами не знаю, но понятно почему начинаются проблемы на больших объемах - из-за вызова триггеров на каждый ряд при массовых изменениях. В этом случае обычно удаляют триггеры и ключи, а затем перестраивают их заново.
Модификация таблиц будет происходить несколько реже чтения, поэтому лишний апдейт поля с фиксированной длиной в диалоге по ключу на вставку сообщения - не слишком большая нагрузка по сравнению с кучей лишних запросов и проще, чем дополнительный слой кеша, который будет делать те же запросы, но чуть реже.
Тем не менее, я, пожалуй, напишу сервис на nodejs, который будет предоставлять интерфейс к этим таблицам и выполнять эти операции заместо триггеров.
А last_message_id должен быть готов всегда - он участвует во всех выборках по conversation. Иначе join либо десяток лишних запросов по ключу. Я предпочитаю кеш в отдельное поле.
Дело в том, что counter не нужно вычислять, это количество сообщений за все время, в том числе удаленных - это должен быть простой инкремент на каждую вставку сообщения.
DieZeeL: да, я такой редкий гость, что отвечаю через год )
в solr есть такая штука как фасетный поиск. и вывести счетчики для категорий - это сущий пустяк
не дергайся - это сомнительный левелап по должностной лестнице. "если знаешь как" - это не способствует прогрессу, а лишь оттачивает навыки. вопрос состоял в том чтобы "пробовать учиться писать свой код, а не править чужой"
