Pull to refresh

Comments 12

Модуль в Yii2 представляется законченной функциональной единицей, содержащей свои контроллеры, модели и представления. Подключение и отключение, условно, не должно приводить к каким бы то ни было бедам. Модули в Yii2 могут содержать в себе другие модули.


Если вы столкнулись с тем, что в нескольких местах используется одинаковая логика контроллера, то имеет смысл рассмотреть использование Standalone actions. Если дублируется view, то путь к view можно задавать используя алиасы. Если и то и то, то есть widgets. Хоть вы и сказали, что они вам не подошли, но я склонен думать, что вы просто неправильно пытались их использовать.


К слову: чем ваше решение отличается от Yii::$app->getModule('moduleName')?

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

К слову: чем ваше решение отличается от Yii::$app->getModule('moduleName')?

Согласен, но тут мы получаем еще некую гибкость в плане управлением состоянием модуля и его позицией на конкретной странице, наш проект это CMS, где пользователю не надо будет лезть в конфиги/контроллер/вид только для того чтоб поменять позицию модуля на странице и т.д. а сделает все через интерфейс в админке сайта.
Спасибо!

Хм, наличие переключателя в админке действительно относительно оправдывает написание своего решения, но, с другой стороны, вы могли это сделать написав класс, реализующий BootstrapInterface. Подключаете его в конфигурации и уже в нём выбираете из БД необходимые настройки модулей и инициализируете их.

да, согласен с Вами, но у нас уже на bootstrap-е есть некая логика и его перегружать такими фичами — не хотелось, а отдать логику управления модулями страницы на контроллеры. Это действие показалось самым логичным на тот момент.

Ну количество Bootstrap методов не ограничено ведь.


Ещё пара идей:


  • Можно переопределить метод getModule() и релизовать внутри необходимый обработчик.
  • Можно в самих модулях, внутри init() методов читать конфигурацию.

Вариантов то много ;) Впрочем я ни в коем случае не намекаю, что ваше решение плохое. Просто можно было обойтись меньшей кровью.

Можно переопределить метод getModule() и релизовать внутри необходимый обработчик.

не плохая идея, даже было реализовано по началу похоже, есть базовый контроллер на котором был метод со всей логикой, но со временем принялось решение отделить «мух от котлет» :)

Нет, я имел в виду заменить оригинальный класс \yii\web\Application и заставить его работать на себя. Так делают, это используют.

у нас приложение полностью состоит из модулей, в каждом модуле есть свою контроллер Controller который наследуется от одного контроллера который в свою очередь уже наследуется от \yii\web\Controller, соответственно на одном уровне абстракции был и реализован данный функционал. Но потом возникла идея реализации модуля по управлению модулями ))

огромное спасибо за конкретную критику и идеи! :)

Правильно ли я понимаю, что вы с помощью модулей сделали некий аналог виджетов с привязой к конкретным позициям?

Делал подобную штуку, но мне хватило функционала виджетов. Как правило все «модули» очень простые. Тот же упомянутый вами опрос. Требуется обработка лишь одного post запроса для голосования. Я делал это внутри run() перед рендером вьюшки. Сейчас уже появилось событие EVENT_BEFORE_RUN и все стало еще проще. Сложные модули типа форума или блога можно раздробить на мелкие (список тем, список сообщений, форма с новым сообщением и тд). Не вижу смысла так усложнять.
спасибо, но я повторюсь была задача не сделать реализацию для одного проекта и пусть оно там работает, а сделать для того чтоб можно было с проекта в проект переносить модули добавляю только запись в БД
Sign up to leave a comment.

Articles