Комментарии 7
Красиво расписал, спасибо.
Спасибо, понятно и доходчиво. Но я ожидал в тексте объяснение, для чего была изменена структура.
Вы бы могли бы ткнуть меня носом где можно прочитать про Сервис-провайдеров, DI-контейнеры.
Для плагинов, изменение способа вызова событий оправдано. Там список методов возвращается в виде массива из метода.
Но для модуля, не понятно для чего меняли структуру. Может Вы знаете концепцию новой структуры модуля?
Условно в старой версии есть точка входа "mod_module.php", мы можем рассматривать вызов этого файла как вызов конструктора в классе. В новой структуре мы можем оперировать объектом модуля в плагинах по мере выполнения этапов работы сайта. Например ПРЕДПОЛОЖУ, объект модуля инициализируется до инициализации компонента, а вот рендер модуля происходит после рендера компонента. Но это лишь моё предположение, Вы знаете очередность этапов работы модуля?
Так же не понятно, почему в диспетчере нужно подключать хелпер, он по сути должен автоматом подключен. Странно.
В новой структуре модуля, возможна работа без диспетчера? Как например компонент Content работает без Controller'а, тут по сути диспетчер тот же конроллер. А значит базовые функции родительского конроллера должны выполнять функции, проброса данных из хелпера в макет модуля, моё предположение.
Из того, что мне удалось найти по теме DI-контейнеров в Joomla - это вот эти 2 ссылки:
В Joomla 4 оно перешло из Joomla Framework. Лично я, признаюсь, так же не совсем пока что понимаю как оно работает, поэтому начинаю пытаться разобраться и в итоге рождаются статьи здесь на хабре. В Joomla 3 модули без хелпера могут работать. В Joomla 4 не пробовал, но, думаю так же вполне могут. Простой вывод данных из настроек модуля не обязательно предварительно обрабатывать хелпером.
Спасибо. В провайдере $container->registerServiceProvider(new HelperFactory('\\Joomla\\Module\\Wtyandexmapitems\\Site\\Helper')); Мы видим что здесь явно указывается что некий класс хелпера модуля является именно хелпером модуля. Таким образом при наличии объекта new HelperFactory() контейнер явно знает стоит ли вызывать Helper из src. Что намекает что модуль должен уметь работать без файла диспетчера и без файла хелпера, на всякий случай. Но если это не так, то это будет очень странно...
$container->registerServiceProvider(new HelperFactory('\\Joomla\\Module\\Wtyandexmapitems\\Site\\Fields')); в провайдере очень подозрительно этот код выглядит. Думается что вместо объектаHelperFactoryдолжен быть какой то другой объект что то вроде FieldFactory. (могу ошибаться). Может CMS инициализирует это пространство имен, но в папке src не находит файл хелпера с именем класса Fields и не загружает его, но это позволяет инициировать пространство имен. Мои догадки. А пространство имен вроде на вывод макета полей вообще ни какой роли не играет.
Кстати прошу Вас присоединиться к моему PR. Это позволит создавать "мультикатегории" для материалов. Прошу Вас поставить там пару лайков!
А Вы документации на Joomla подсмотрели новую структуру или на примере другого модуля изучали?
Если в следующей версии Joomla поддержку старой структуры модулей, то это будет начало конца для Joomla, по крайней мере не разумный шаг уж точно.
В четвёрке в методе countModules появился второй булев параметр withContentOnly, что-то такое, не у компа сейчас. То есть если модуль есть, но и вывода нет, то не должно быть пустых колонок в шаблоне
Изучали тему коллеги по чату Joomla-сообщества с год назад в связи с ajax в модулях, из тех дискуссий полезной оказалась информация, что по новому канону сделан только модуль вывода иконок в админке. А дальше реверс инжиниринг))) И анализ модулей из расширений Akeeba, так как Николас - разработчик и фаундер Akeeba - один из локомотивов кодовой базы joomla.
PR смотрели?, поставьте там пару лайков и поддержите.
Спасибо, Akeeba модули посмотрю обязательно.
Создание модулей с учётом новой структуры Joomla 4