Как зарегистрировать стили в модуле Yii2?

Question

[Константин Марченко]

Всем примет и хорошего дня!
Создал модуль. Как в представлении подключить файл стилей? Нет, ну я знаю какими способами это можно сделать.
Есть возможность через функцию $this->registerCssFile('***'); либо через создание класса:

public $sourcePath = '@app/modules/***';    
    public $css = [
        'css/data/data.css',
    ];

Второй способ отлично работает, но меня не устраивает что стили подключаются везде при нахождении в любом месте модуля. А хотелось бы точечно подключать, тоесть в каком нибудь представлении (views/view.php) через $this->registerCssFile('***');. Но так не подключается, я так понимаю что причина в пути для модуля. В обычных представлениях это работает. Но вот в случае с модулем нет. Можно ли разрулить этот неловкий ситуейшн ? :)

Comments

[Дмитрий]

День добрый.
Создаёте класс расширяющий AssetBundle и подключаете его где хотите.
$this->register(Your_class);

[Константин Марченко]

Дмитрий, Это вы говорите, создать общий класс AssetBundle и разместить в нем код:

public $sourcePath = '@app/modules/***';    
    public $css = [
        'css/data/data.css',
    ];

Это работает! Все подключил и все ок.
Но было бы лучше если можно подключить было бы файл стилей ИЗ представления по средством функции $this->registerCssFile('***');

[Дмитрий]

Константин Марченко, не общий класс, а класс специально для модуля, только модуль будет его использовать.

Но было бы лучше если можно подключить было бы файл стилей ИЗ представления

Ну подключайте так, проблема в чём?

[Константин Марченко]

Дмитрий, Все ок уже, разобрался) Спасибо за помощь!

Answer 1

[Максим]

1. Скорее всего модуль в вашей системе будет лишним. Так как большинство не понимают его использование. Модуль это независимая часть приложения, которая слабо зависима от других. Например, shop, blog, auth, gii и так далее. Поэтому подумайте, стоит ли код выносить в модуль. Если нет, то и вопрос решается общим подключением. В 90% случаях он не нужен. Чаще всего он используется для выделения расширения и подключения через composer. Модульность можно заменить разделением папок в проекте.

2. Подключать в представлении можно любой AssetBundle

use app\assets\AppAsset;
AppAsset::register($this);  // $this - представляет собой объект представления

Comments

[Константин Марченко]

Ну в моем случае лучше в модулях, у меня глобальное идет разделение сайта на два направления - это юридическое лицо и физическое. Я уже задавал тему на этот счет: Как выстроить правильную структуру контроллера YII2?
Тоесть при авторизации если это физ лицо то идет перенаправление на путь физ лица, если юр, то на путь юр лица.... тут прикол в том что уровень вложенности экшенов может быть достаточно глубоким. Я вначале делал на контроллерах и передавал туда параметр, но в итоге все это разрастается и становится сложно этим управлять. Через модули проще и понятней, поетому и выбрал такой путь)

[Максим]

Константин Марченко, ещё раз говорю. Модули это не про вложенность и не про URL! Модуль ничем не отличается от папки в action. Ничем! В модуль выноситься уже реально независимая часть сайта. Если вы не с этой точки зрения подходите - забудьте про модульность.

Более того. Разделение на модули несёт много проблем с их подключением, взаимодействием и работой. Подумайте что раз)

[Максим]

Константин Марченко, разделение на физические лица и юридические слабо представляю в модульности. У вас это будет объедено в одной CRM. То что у них разные UI это вопрос уже другой. Поэтому, вы однозначно выбрали не правильную архитектуру. По вашей логике вам нужны разные права доступа для работы с физ и юр лицами. Чаще всего работа с клиентами ведётся в CRM, где имеют доступы менеджеры. Вот CRM и будет модулем. А у вас непонятки.

[Константин Марченко]

Максим, А почему нет то? Я создал два модуля /legal и /phys . В каждом из них будут свои контроллеры для работы и представления. Я настроил автонаправление после авторизации. Тоесть, если авторизовался физ лицо то его автоматически направляет на модуль /phys, если же юр лицо вошло то его направляет на /legal.
Тоесть каждый работает на своем пути. Все пути у физ лица будут /phys/controller/action а у юр соответственно /legal/controller/action. Но при этом пути вложенностей экшеннов может быть больше.
Почему так нельзя то? Разделение прав тут явно не поможет, потому что у юр лица и физ лица КООРДИНАЛЬНО отличаются интерфейсы. А пилить всё на контроллерах и маршрутизации через urlManager это по сути - всё в одну кашу скидывать.

[Максим]

Константин Марченко, Окей. У вас один сотрудник авторизовался. Он работает с физ и юр лицами. Куда его перенаправите?)

В общем архитектура у вас не подходящая. Можете спорить сколько угодно. Модули вам не нужны.

Что мешает сделать?

controllers/legal/client/ShowController::index()????

Вопрос не архитектуре. Решение я вам дал.

[Константин Марченко]

Максим, у меня сотрудников нету. пользователи ВСЕ разделены на физ лица и юр лица. только два направления. не может физ лицо работать И с юр лицами. Ты регистрируешься ЛИБО юр лицом ЛЮБО физ лицом. О каком сотруднике вы говорите который может работать под физ лицом С юр лицами?!?!

[Максим]

Константин Марченко, это сейчас нет. Завтра вам понадобиться с клиентами работать. Закрывать на сделки, контролировать продажи. Вы наймёте менеджера, который будет работать с этой базой. В этой базе он будет делать различные пометки: готов оплатить, первая заявка и т д....

[Константин Марченко]

Максим, Если описать подробнее. У меня регистрируется пользователь как юр лицо - это работадатель! Потом регистрируется пользователь как физ лицо и через связи подает запрос на устройство на работу с ранее зарегистрированным юр лицом. Это юр лицо дает согласие И У СЕБЯ в интерфейсе включает этому физ лицу разделы с которыми он может работать. Это могут быть Заказы, Звонки входящие, Договора и т.д.
Соответственно физ лицо у себя в своем интерфейсе видит что у него появились разделы выше указанные которые ему одобрило юр лицо. И всё и далее физ лицо работает с этими разделами. Это только вершухка айзберга...
Надеюсь понятно обьяснил)

[Константин Марченко]

Максим, вы видимо недоконца поняли что за система у меня....ладно в общем все равно спасибо за уделенное время)

[Максим]

Константин Марченко, не понятно. Юр лица и физ лица !== сотрудники. У сотрудников могут быть свои поля: зарплата, ставка, должность.... вот вам тема с форума https://www.sql.ru/forum/1143585-2/tablicy-users-i...

[Максим]

Константин Марченко, ваша система простая, если не вникать в тонкости. А вот про модульность вы точно не поняли) Почитайте) Ответ я вам в любом случае дал...

Модули - это законченные программные блоки, состоящие из моделей, представлений, контроллеров и других вспомогательных компонентов.

[Константин Марченко]

Максим, физ лица - это и есть сотрудники. А юр лица это работодатель у которых и работают эти сотрудники. Они обрабатывают заказы , принимают звонки , работают с договорами и т.д. Я наверно в предыдущем сообщении не правильно выразился. Сотрудники это физ лица, тоесть работники а юр лицо это работодатель который либо берет на работу зарегистрировавшегося сотрудника (физ лица) либо нет.

[Максим]

Константин Марченко, в общем ладно) Вы даже сами говорите, что юр лица берут на работу физ лиц, но при этом у вас два разных модуля. Вы не поняли до конца смысл модульности. У вас это CRM! Чтобы понять, что такое модуль - вы просто удалите весь модуль (всю папку модуля) из вашего приложения. Система продолжает работать? Тогда вы все сделали правильно. И модульность вы поняли. А если нет, то увы. Модульность вы не поняли зачем.

Ещё раз говорю. Модуль это НЕЗАВИСИМОСТЬ! При удалении блога CRM никак не должна прекратить свою работу. И наоборот. А если у вас все связано - это не модули. Модули в таком случае служат у вас для разделения кода. А разделять код можно и ПАПКАМИ!) При этом не надо будет мучаться со всеми сложностями мудульности.

Что может быть модулем?
CRM
СКЛАД
БЛОГ
МАГАЗИН
и т д

[Максим]

Константин Марченко, поняли или нет? У вас физ лица сильно связаны с юр лицами. С чего вы разделяете это на модули? Удалите в базе таблицу фил лиц и ваша система полетит. Это не модуль. У модуля свои таблицы, которые не зависят от других. Либо слабо связаны.

[Максим]

Константин Марченко, https://m.habr.com/ru/post/276593/

[Максим]

Константин Марченко,

Модуль — это не произвольный кусок кода, а отдельная функционально осмысленная и законченная программная единица (подпрограмма), которая обеспечивает решение некоторой задачи и в идеале может работать самостоятельно или в другом окружении и быть переиспользуемой. Модуль должен быть некой "целостностью, способной к относительной самостоятельности в поведении и развитии" (Кристофер Александер).

[Константин Марченко]

Максим, хм, про модульность понял. Ну ок, допустим делаем разделение без модулей. В каком виде мне это сделать? Я так понимаю что в urlManager я создаю (к примеру) следующее:

'<controller>' => '<controller>', //это для /phys/index и /legal/index

Это как пример начала работы. Тоесть у физ лица свой контроллер, у юр свой. У каждого из них есть свой раздел настроек. так называемый settings. Тоесть, у физ лица это /phys/settings а у юр это /legal/settings.
Еще раз - это просто как пример. Тоесть далее по логике вещей settings это экшн контроллеров legal и phys. Тут все понятно. Но вот что если в разделе settings есть еще доп раздел внутри него. Тоесть к примеру /phys/settings/data. Data это раздел у которого могут быть свои внутренние экшены. К примеру /phys/settings/data/create или /phys/settings/data/update.
Так вот как работать с такой вложенностью? Я так понимаю что надо написать что-то подобное?:

'<controller>' => '<controller>', //это для /phys/index и /legal/index
'<controller><action>' => '<controller><action>', //phys/settings и /legal/settings
'phys/settings/data' => 'data/index'
'phys/settings/data/<action>' => 'data/<action>'
                'legal' => 'legal/index'

Тоесть создавать Контроллер Data? со своими экшенами или как? Понимаете мне не нравится что все контроллеры в одной папке лежат, мне нужно какое-то разделение. Отделить все что связано с юр лицами от физлиз. В модульности это было проще сделать (ну как по мне). Но если есть возможность без них, то как правильно это сделать С УЧЕТОМ моей глубокой вложенности экшенов?

[Максим]

На модульность вас как раз и запутал urlManager. В этом ваша проблема, а не в структуре папок!

Здесь нужно понимать 2 вещи:

1. URL Manager работает с простыми регулярными выражениями. Регулярные выражения знаете? Если да, то проблем не возникнет.

Вы когда-то замечали, что контроллер может быть написан как <_с>? Вы можете сделать свои регулярные выражения вроде <_l>/<_c>/<_d>. Почитайте регулярные выражения.

2. Yii2 сделан по типу RAD это быстрая разработка. стандартные правила URL Manager не подойдут для сложных условий. Поэтому, я делаю все правила в отдельном файле route.php и подключаю весь список через отдельный файл. Вы наверняка замечали подобное в других фреймворках или Vue.

В этом файле могут быть любые ПОНЯТНЫЕ и ПРЕДСКАЗУЕМЫЕ правила:

return [
    //Event
    '/event/' => '/event/default/index',
    '/event/manage' => '/event/default/manage',
    '/event/id<id:\d+>' => '/event/default/view',
    '/event/create' => '/event/default/create',
    '/event/<id:\d+>/update' => '/event/default/update',
    '/event/<id:\d+>/delete' => '/event/default/delete',
    '/event/<id:\d+>/clone' => '/event/default/clone',
    '/event/<id:\d+>/poster/upload' => '/event/event/poster/upload',
    '/event/<id:\d+>/poster/remove' => '/event/event/poster/remove',
    '/event/<id:\d+>/status/cancel' => '/event/event/status/cancel',
    '/event/<id:\d+>/status/activate' => '/event/event/status/activate',
    '/event/<id:\d+>/date/move' => '/event/event/date/move',
    '/event/<event_id:\d+>/org-committee/add' => '/event/event/org-committee/add',
    '/event/<event_id:\d+>/org-committee/<id:\d+>/edit' => '/event/event/org-committee/edit',
    '/event/<event_id:\d+>/org-committee/<id:\d+>/remove' => '/event/event/org-committee/remove',
    '/event/with-users' => '/event/default/with-users',
    '/event/calendar' => '/event/calendar/index',
];

Слева правило. Справа путь.

Вы можете либо сложными регулярными выражениями, либо простыми из второго примера. Первый вариант сложен подбором. Второй более простой и понятный. Но на больших проектах возможно придётся оптимизировать. Но я ни разу не оптимизировал

[Константин Марченко]

Максим, /event//poster/upload' => '/event/event/poster/upload',

хм... два event справа, первый это контроллер? Вот мне именно это и нужно понять. Просто в yii может быть только controller/action, тоесть контроллер-действие. Если смотреть на вашем примере /event/event/poster/upload, то event это контроллер, второй ивент это экшн))) Блин у меня голова разболелась))) Так вот, а что тогда у вас poster/upload ? параметры которые передаются во второй экшн event? или что это?

[Максим]

Константин Марченко, два event появились от того, что event это от того что группируется код. Но можно обойтись и без этого.

У меня слишком методов, которые относятся к мероприятию. Чтобы это не пихать все в один контроллер я объединил все действия для работы с ОДНИМ событием в отдельную папку event. В итоге у меня получилось так:

controllers/
    event (по аналогии с модулем)
       DefaultController (здесь все actions по работе с массовыми действиями, создание, массовое удаление, отображение и т д) контроллер можно и назвать EventsController. 
        event (по работе с одной единицей: удаление, загрузка изображение, удаление, активация, блокировка, редактировать...)
           StatusComtroller (активировать, деактивировать)
           PosterController (загрузить, удалить)
           EventController (редактировать, просмотр, удалить)

[Константин Марченко]

Максим, запросил доступ

[Константин Марченко]

Максим, Спасибо посмотрел! Но у меня почему то так не срабатывает, точнее не совсем так, я пишу (просто сделал для примера чтобы проверить работу):

'/phys' => '/phys/phys/index', //а вот тут нет....в папке /phys лежит контроллер Phys с экшином index, и он не видит его...
'/phys/data' => '/phys/default/index', //это сработало по контроллеру default

[Максим]

Константин Марченко, у вас наверное есть какие-то другие правила по мимо этих. Уберите их временно

[Константин Марченко]

Максим, Все заработало! Модуль phys созданный ранее перекрывал маршрут, отключил и заработало! Все я понял теперь как надо! Огромнейшее спасибо!)

[Максим]

Константин Марченко, не за что. Но и про модульность разберитесь. У вас это не два разных модуля)

[Константин Марченко]

Максим, да я понял разницу в модулях, просто видимо не догнал изначально работу urlManager, и переключился на них.

[Максим]

Константин Марченко, видимо) Об этом и говорю, что он вас сбил с толку.