Это вы сами закастомайзили дизайн yii-debug-toolbar'а или он такой в новых версиях? Неплохо выглядит.
Мне вот не хватает возможности включать/выключать тулбар get-переменной, которая потом сохраняется в сессии, надо будет как-то набросать такой костылик.
Еще очень кстати была бы вкладочка с переменными, которые передаются во вьюшки, это правда придется в рендерер внедряться, но если это получится сделать к примеру миксином, который через конфиг можно будет присобачить к любому рендереру — было бы чудесно. (Может такое уже есть, тогда делитесь ссылкой)
1) От общего контроллера конечно же не обязательно наследоваться.
У меня в проектах все контроллеры наследуются от класса Controller, который создается по дефолту консольными инструментам и это, можно сказать, неписаное правило (а может и есть какие-то рекомендации), наследовать все свои контроллеры не напрямую от CController, а от Controller (очень многие разработчики расширений именно так и делают), который в свою очередь является прекрасным способом внедрения проектно-специфческого функционала в 3rd-party расширения без вмешательства в их код.
Так вот, еще одна хорошая практика — мерджить фильтры каждого контроллера с фильтрами родительского класса, если нужно что-то добавить.
И если мы используем такой подход, не нужно в сотнях мест что-то править, достаточно добавить фильтр модуля Rights в класс Controller.
2) Раздел «на сладкое» я бы рекомендовал убрать/перечеркнуть, т. к. это, как уже сказали, реализуется бизнес-правилами (!Yii::app()->user->isGuest;) и не нужно ничего хранить в базе для каждого пользователя.
Кстати, аналогично можно написать бизнес-правило для определения админов, чтобы не городить лишнего: UserModule::isAdmin();
(я так и делаю)
Есть еще моя ветка в репозитории Yii-user с мелкими правками, без которых (лично мне) никак, в основном это вынос всего что чаще всего приходится кастомизировать в конфиг, чтобы можно было обвешать проектно-специфическими миксинами, фильтрами, обработчиками событий.
Вещи типа универсальной корзины думаю, удобнее делать behavior'ами для модели (если хочется универсальности).
Я например использую behavior для хранения автора/даты создания/даты последней правки (кроме добавления геттеров и сеттеров поведение навешивает на модель события beforeSave/afterSave, beforeValidate/afterValidate).
И версионность, с ней по-моему особенно удачно получилось. Поведение (behavior) создает новую таблицу по подобию таблиц owner'а с суфиксом '_revisions', расширяет первичный ключ таблицы колонкой 'revision' и навешивает модели обработчик afterSave, который дополнительно сохраняет запись в таблицу с ревизиями. А также добавляет модели методы для работы с этим всем добром.
Если система разрабатывается изначально с версионностью, конечно же, лучше ее реализовать как родную, чтобы избежать лишнего запроса при сохранении и дублирования данных. Но вот к куче существующих модулей добавить таким образом эту фичу получилось просто отлично.
И еще: да, описанный sdevalex'ом подход вполне имеет право на жизнь, но очень много удобства все-таки добавляет кодогенератор, собственные шаблоны рулят.
p.s.: Оформляйте в виде расширения и выкладывайте на Yii extensions!
Спасибо! Хорошая штука.
Буду очень признателен за наводку на что-то похожее для хрома/хромиума, т. к. пока для этого приходится юзать порно-режим, который все-таки преследует несколько иные цели и не максимально удобен для этого ))
Должно. К примеру потому что контроллеры backend'а этого модуля не наследуются от предложенного вами BackEndController и не лежат директории /controllers, а не /controllers/backend
Подход интересный, но он может иметь место если вы не используете сторонние модули в своих проектах. Отказ от огромной базы расширений Yii, имеющих собственный backend все же — не самый верный шаг.
Хотя, если вы знаете универсальный путь, как подружить такой подход с 3rd party extensions — мне было бы очень интересно почитать.
Ок, ясно. Думал, есть такое определение, но нагуглить не удалось.
Можно было бы в статье кстати хоть бегло рассказать (раз уж используется какой-то особый термин) что еще инвесторы могут дать кроме денег (лично мне интересно), хотя может это тема для отдельной статьи.
Мне вот не хватает возможности включать/выключать тулбар get-переменной, которая потом сохраняется в сессии, надо будет как-то набросать такой костылик.
Еще очень кстати была бы вкладочка с переменными, которые передаются во вьюшки, это правда придется в рендерер внедряться, но если это получится сделать к примеру миксином, который через конфиг можно будет присобачить к любому рендереру — было бы чудесно. (Может такое уже есть, тогда делитесь ссылкой)
1) От общего контроллера конечно же не обязательно наследоваться.
У меня в проектах все контроллеры наследуются от класса Controller, который создается по дефолту консольными инструментам и это, можно сказать, неписаное правило (а может и есть какие-то рекомендации), наследовать все свои контроллеры не напрямую от CController, а от Controller (очень многие разработчики расширений именно так и делают), который в свою очередь является прекрасным способом внедрения проектно-специфческого функционала в 3rd-party расширения без вмешательства в их код.
Так вот, еще одна хорошая практика — мерджить фильтры каждого контроллера с фильтрами родительского класса, если нужно что-то добавить.
И если мы используем такой подход, не нужно в сотнях мест что-то править, достаточно добавить фильтр модуля Rights в класс Controller.
2) Раздел «на сладкое» я бы рекомендовал убрать/перечеркнуть, т. к. это, как уже сказали, реализуется бизнес-правилами (!Yii::app()->user->isGuest;) и не нужно ничего хранить в базе для каждого пользователя.
Кстати, аналогично можно написать бизнес-правило для определения админов, чтобы не городить лишнего: UserModule::isAdmin();
(я так и делаю)
Я эти два модуля именно в такой связке и юзаю.
Есть еще моя ветка в репозитории Yii-user с мелкими правками, без которых (лично мне) никак, в основном это вынос всего что чаще всего приходится кастомизировать в конфиг, чтобы можно было обвешать проектно-специфическими миксинами, фильтрами, обработчиками событий.
Я например использую behavior для хранения автора/даты создания/даты последней правки (кроме добавления геттеров и сеттеров поведение навешивает на модель события beforeSave/afterSave, beforeValidate/afterValidate).
И версионность, с ней по-моему особенно удачно получилось. Поведение (behavior) создает новую таблицу по подобию таблиц owner'а с суфиксом '_revisions', расширяет первичный ключ таблицы колонкой 'revision' и навешивает модели обработчик afterSave, который дополнительно сохраняет запись в таблицу с ревизиями. А также добавляет модели методы для работы с этим всем добром.
Если система разрабатывается изначально с версионностью, конечно же, лучше ее реализовать как родную, чтобы избежать лишнего запроса при сохранении и дублирования данных. Но вот к куче существующих модулей добавить таким образом эту фичу получилось просто отлично.
И еще: да, описанный sdevalex'ом подход вполне имеет право на жизнь, но очень много удобства все-таки добавляет кодогенератор, собственные шаблоны рулят.
p.s.: Оформляйте в виде расширения и выкладывайте на Yii extensions!
Буду очень признателен за наводку на что-то похожее для хрома/хромиума, т. к. пока для этого приходится юзать порно-режим, который все-таки преследует несколько иные цели и не максимально удобен для этого ))
Коротко, емко, как-раз ок для значка )
А в подготовительных вопросах их существовало больше, чем эти 90, что в PDFке?
Хотя, если вы знаете универсальный путь, как подружить такой подход с 3rd party extensions — мне было бы очень интересно почитать.
Можно было бы в статье кстати хоть бегло рассказать (раз уж используется какой-то особый термин) что еще инвесторы могут дать кроме денег (лично мне интересно), хотя может это тема для отдельной статьи.