Новости Joomla

Как триггерить события для плагинов на манер Joomla 5+?В Joomla 6 должны удалить метод...

Как триггерить события для плагинов на манер Joomla 5+?В Joomla 6 должны удалить метод...

👩‍💻 Как триггерить события для плагинов на манер Joomla 5+?В Joomla 6 должны удалить метод triggerEvent(), с помощью которого раньше вызывались события для плагинов. Теперь чтобы в своём коде вызвать событие для плагина и получить от него результаты нужно:- создать объект класса события- передать в него параметры

use Joomla\CMS\Event\AbstractEvent;use Joomla\CMS\Factory;use Joomla\CMS\Plugin\PluginHelper;// Грузим плагины нужных группPluginHelper::importPlugin('system');// Создаём объект события$event = AbstractEvent::create('onAfterInitUniverse', [    'subject' => $this,    'data'    => $data, // какие-то данные    'article' => $article, // ещё материал вдовесок    'product' => $product, // и товаров подвезли]);// Триггерим событиеFactory::getApplication()->getDispatcher()->dispatch(    $event->getName(), // Тут можно строку передать 'onAfterInitUniverse'    $event);// Получаем результаты// В случае с AbstractEvent это может быть не 'result',// а что-то ещё - куда сами отдадите данные.// 2-й аргумент - значение по умолчанию, // если не получены результаты$results = $event->getArgument('result', []);
Плюсы такого подхода - вам не нужно запоминать порядок аргументов и проверять их наличие. Если вы написали свой класс события, то в плагине можно получать аргументы с помощью методов $event->getArticle(), $event->getData(), $event->getProduct() и подобными - реализуете сами под свои нужды. Если такой класс события написали, то создаёте экземпляр своего класса события и укажите его явно в аргументе eventClass
use Joomla\Component\MyComponent\Administrator\Event\MyCoolEvent;$event = MyCoolEvent::create('onAfterInitUniverse', [    'subject'    => $this,    'eventClass' => MyCoolEvent::class, // ваш класс события    'data'       => $data, // какие-то данные    'article'    => $article, // ещё материал вдовесок    'product'    => $product, // и товаров подвезли]);
Ожидаемо, что класс вашего события будет расширять AbsractEvent или другие классы событий Joomla.🙁 Есть неприятный нюанс - нельзя просто так вызывать событие и ничего не передать в аргументы. Аргумент subject обязательный. Но если вы всё-таки не хотите туда ничего передавать - передайте туда пустой stdClass или объект Joomla\registry\Registry.
@joomlafeed#joomla #php #webdev

0 Пользователей и 1 Гость просматривают эту тему.
  • 7 Ответов
  • 2371 Просмотров
*

zaboich

  • Осваиваюсь на форуме
  • 37
  • 11 / 0
Исходные данные.
Для разработки расширения Joomla, например компонента, надо иметь:
1. «Установочный» каталог расширения. В этом каталоге хранятся файлы расширения в виде установочного пакета. Например:
Код
/mycomp/ # корневой каталог расширения
/mycomp/admin/ … # каталог с файлами административной части
/mycomp/site/ … # каталог с файлами публичной части
/mycomp/com_mycomp.xml # описание расширения и инсталяционный скрипт

Из этого каталога собирается установочный пакет.

2. Тестовый сервер с каталогом сайта для тестирования.
Важное замечание: на сайте каталоги и файлы расширения разбросаны совсем не так, как в установочном пакете.

3. Редактор кода или среда разработки (IDE), с помощью которого код пишется.
4. Не обязательно, но фактически стандарт: репозиторий git + удаленный репозиторий github

Набор не большой и вполне стандартный для разработки, но есть одна неприятная сложность : структура установочного пакета = структуре хранения файлов на github != структуре файлов на тестовом сервере.

Таким образом мне видятся два варианта работы:
1. Настроить редактор на работу с файлами в «установочном» каталоге расширения.
Тогда после каждой правки, собираем пакет -> устанавливаем на тестовый сервер -> тестируем изменение.
Понятно, что git настроен на работу с каталогом расширения.
Плюсы:
+ установочный пакет всегда готов
Минусы:
- большие затраты на тестирование изменение
- установочный пакет не всегда работоспособен

2. Можно настроить редактор на работу с файлами тестового (имеет смысл только локального) сервера.
Тогда тестировать можно сразу после правки. Что бы собрать тестовый пакет надо скопировать все необходимые файлы из различных каталогов тестового сайта в каталог расширения.
Git может быть настроен на один из этих каталогов или сразу на два — контролировать и каталог расширения или/и файлы расширения в тестовом сайте.
Плюсы:
+ быстрое тестирование
+ установочный пакет всегда работоспособен
+ каталог установки версионируется без git
Минусы:
- если версионируется установочный каталог — IDE не дает подсказок о необходимости сделать коммит.
- если версионируется каталог тестового сервера, структура файлов в репозитории git не соответствует пакету установки.

Держать два репозитория git – в каталогах разработки, на тестовом сервере и в каталогах установки можно, но это усложняет систему и увеличивает возможность что-нибудь забыть.

Я использую вариант с редактированием и версионированием файлов в каталогах сервера, но  регулярно сталкиваюсь с различными неудобствами связанными с необходимостью вести несколько веток, которые в рамках одного сайта не всегда совместимы.

Возможно есть какие-то лучшие способы объединить разработку, тестирование и версионирование расширений.
Предлагаю желающим поделится опытом настройки рабочей среды разработки.
« Последнее редактирование: 25.08.2015, 01:39:41 от zaboich »
*

b2z

  • Глобальный модератор
  • 7287
  • 778 / 0
  • Разраблю понемногу
Вариант 1, только ничго не собираю - в проекте настроен деплой на тестовый сервер и все ;) Мне кажется любая IDE такое позволяет сделать.
*

zomby6888

  • Завсегдатай
  • 1473
  • 171 / 3
Использую второй вариант. На тестовом локальном сервере устанавливается каркас расширения. Потом после необходимых доработок и тестирования, при помощи phing собирается установочный пакет одним щелчком мыши. git не использую. На первый вариант мне кажется ушло бы куда больше времени, так как тестировать изменения приходится постоянно.
« Последнее редактирование: 04.08.2015, 23:50:19 от zomby6888 »
интернет-блог: http://websiteprog.ru
*

b2z

  • Глобальный модератор
  • 7287
  • 778 / 0
  • Разраблю понемногу
Уточню, как я работаю.

Под гитом проект со структурой сборки:
/admin
/site
/media
extension.xml // Манифест расширения
build.xml // Phing манифест

Все папки проекта настроены на авто-деплой на локальный сервер. Если нужен деплой на тестовый сервер, то либо собираю установочный пакет, либо делаю деплой нужных файлов. В PhpStorm деплои очень легко настраиваются.
*

zaboich

  • Осваиваюсь на форуме
  • 37
  • 11 / 0
Спасибо!
Автоматизация этих процессов сильно упрощает дело и превращает довольно много работы из долгой рутины в почти мгновенную магию :)

Уточню, как я работаю.
Немного не понятно в такой конфигурации:
1. Как PhpStorm получает данные об API Joomla чтобы использовать в подстановках кода, если в проекте только файлы самого расширения? К проекту include каталог распакованная Joomla?
2. Как происходит отладка, отслеживание переменных? Код запускается за пределами проекта IDE => возможности PhpStorm по отладке не используются.
3. Чем занимается Phing, если деплой происходит силами PhpStorm?
*

b2z

  • Глобальный модератор
  • 7287
  • 778 / 0
  • Разраблю понемногу
1. include репы joomla-cms, котора у меня постоянно на диске
2. В проекте создана папка www с неотслеживаемыми файлами, которые являются симлинками на файлы локального сервера:
/www/administrator/index.php
/www/index.php
Это точки входа для дебага
3. Phing занимается конечной сборокой архива релиза. Почитайте:
http://joomlaportal.ru/blogs/extensions/2551-phing-xml-joomla
*

zaboich

  • Осваиваюсь на форуме
  • 37
  • 11 / 0
Вначале показалось, что вариант zomby6888 с использованием Phing для сборки пакета более интуитивный.
Но в этом варианте возникают сложности с настройкой Git, так что бы получить в удаленном репозитории, например на github`е, готовый установочный пакет с возможностью установки из него.
*

zomby6888

  • Завсегдатай
  • 1473
  • 171 / 3
Ну я с git не работаю, как я уже писал, но тоже проблемы особо не вижу. Вы же можете создать репозиторий из любой папки. Чтобы отслеживать изменения вы можете в PhpStorm в папку с проектом инклудить папку с сборкой(include Path в настройках PHP проекта). Создаете репозиторий из папки со сборкой и делаете оттуда и push/pull реквесты.
« Последнее редактирование: 14.08.2015, 16:55:06 от zomby6888 »
интернет-блог: http://websiteprog.ru
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Условия отображения для конкретной группы пользователей Joomla 3.4.x

Автор dmik

Ответов: 15
Просмотров: 3235
Последний ответ 29.05.2020, 22:42:15
от voland
Подключить Joomla Framework в своем файле

Автор kolhoz

Ответов: 1
Просмотров: 1778
Последний ответ 06.12.2017, 17:15:42
от Aleks.Denezh
Переделать запросы к БД под Joomla

Автор Glog

Ответов: 3
Просмотров: 1478
Последний ответ 03.07.2017, 17:53:28
от Glog
Настройка ReCAPTCHA

Автор Region93

Ответов: 8
Просмотров: 1386
Последний ответ 24.04.2017, 20:48:31
от Aleks.Denezh
Поддержка Joomla в PhpStorm

Автор b2z

Ответов: 51
Просмотров: 11287
Последний ответ 28.12.2016, 23:31:39
от b2z