Size: a a a

2020 May 01

OK

Oleg Kuzmenko in Yii Framework 2
Мне просто концепция работы с ивентами в Yii 2 вообще не нравится
источник

СП

Сергей Предводителев... in Yii Framework 2
Добрый день!

Что значит вот эта опция в composer.json:
"config": {
       "fxp-asset": {
           "enabled": false
       }
   },
?
источник

ДК

Дмитрий Кожанов... in Yii Framework 2
Сергей Предводителев
Добрый день!

Что значит вот эта опция в composer.json:
"config": {
       "fxp-asset": {
           "enabled": false
       }
   },
?
Позволяет рулить бандлами npm без npm
источник

СП

Сергей Предводителев... in Yii Framework 2
Дмитрий Кожанов
Позволяет рулить бандлами npm без npm
Это про пакеты npm-asset/* ?
источник

ДК

Дмитрий Кожанов... in Yii Framework 2
Сергей Предводителев
Это про пакеты npm-asset/* ?
Ага
источник

СП

Сергей Предводителев... in Yii Framework 2
Понял, спасибо!
источник

O

OSW in Yii Framework 2
Дмитрий Кожанов
Позволяет рулить бандлами npm без npm
@grandmotivator reacted to a message from @Med1c84 (4)
источник

OK

Oleg Kuzmenko in Yii Framework 2
Alex
Сто методов городить ненадо, такой код невозможно будет поддерживать ) в мире ооп нужно оперировать интерфейсами
источник

OK

Oleg Kuzmenko in Yii Framework 2
Книга гласит, что надо делать так, как я бы того не хотел
источник

NO

Nex Otaku in Yii Framework 2
Олег, зачем вообще понадобились события, я так и не понял?
источник

NO

Nex Otaku in Yii Framework 2
События часто вносят путаницу, так как добавляют невидимые связи в коде. Логику выполнения кода и все побочные эффекты становится сложно отследить. Поэтому, их используют редко.

Самый частый пример использования событий - это привязка к событиям внешних компонентов.

Сделал некий разработчик свой универсальный компонент, и не знает, как его компонент будет использоваться. Хочется и предоставить возможность расширенного использования, и при этом не сильно менять логику.

Поэтому автор компонента прописывает генерацию события, допустим "Письмо отправлено". Мы, подключив этот компонент, в приложении "ловим" событие и увеличиваем какой-нибудь счётчик или пишем в лог. Или не подписываемся на событие и игнорируем его.

Концепция очень простая, поэтому кое-где используется )

Но в коде самого приложения я не вижу причин делать связь через события...
источник

T🐜

The Ant 🐜 in Yii Framework 2
в целом согласен. если БЛ предполагает отправку письма, то в очередь кидаем все необходимые данные для этого действия именно в сервисе, А в очереди уже другой сервис занимается отправкой писем по исходным данным. Про билдер уже сказали :)
Тамщемта, уиишный свифт маилер и есть билдер. Дополнительно там городить имхо нет смысла
источник

TS

Tagil Steel in Yii Framework 2
Nex Otaku
Олег, зачем вообще понадобились события, я так и не понял?
Есть такая вещь в ООП - множественное наследование. В принципе, она помогает делать код стройнее и понятнее.
Нативный способ иммитации множественного наследования - это трейты. С большими ограничениями.
А способ Yii - это поведения, подписывающиеся на события. Ограничений значительно меньше, но тормозов больше.
источник

OK

Oleg Kuzmenko in Yii Framework 2
Nex Otaku
События часто вносят путаницу, так как добавляют невидимые связи в коде. Логику выполнения кода и все побочные эффекты становится сложно отследить. Поэтому, их используют редко.

Самый частый пример использования событий - это привязка к событиям внешних компонентов.

Сделал некий разработчик свой универсальный компонент, и не знает, как его компонент будет использоваться. Хочется и предоставить возможность расширенного использования, и при этом не сильно менять логику.

Поэтому автор компонента прописывает генерацию события, допустим "Письмо отправлено". Мы, подключив этот компонент, в приложении "ловим" событие и увеличиваем какой-нибудь счётчик или пишем в лог. Или не подписываемся на событие и игнорируем его.

Концепция очень простая, поэтому кое-где используется )

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

ПГ

Павел Грибалёв... in Yii Framework 2
Nex Otaku
События часто вносят путаницу, так как добавляют невидимые связи в коде. Логику выполнения кода и все побочные эффекты становится сложно отследить. Поэтому, их используют редко.

Самый частый пример использования событий - это привязка к событиям внешних компонентов.

Сделал некий разработчик свой универсальный компонент, и не знает, как его компонент будет использоваться. Хочется и предоставить возможность расширенного использования, и при этом не сильно менять логику.

Поэтому автор компонента прописывает генерацию события, допустим "Письмо отправлено". Мы, подключив этот компонент, в приложении "ловим" событие и увеличиваем какой-нибудь счётчик или пишем в лог. Или не подписываемся на событие и игнорируем его.

Концепция очень простая, поэтому кое-где используется )

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

OK

Oleg Kuzmenko in Yii Framework 2
Павел Грибалёв
Ну ююишные эвенты может и не самые удобные. Но утверждение, что эвенты используются редко спорное.
Когда при добавлении товара например тебе нужно переиндексить товар в эластике, сгенерить превьюхи, зафиксировать какой пользователь создал или изменил товар, при изменении количества товара в наличии еще произвести манипуляции и прочая прочая логика. Ты будешь это все в сервисе писать? 5 раз пушить в очередь и делать 5 джобов?)) Написать свой диспатчер в простом виде и эвенты это дело 20 минут.
Вот самое неприятное — так это то, что в Йии надо пилить свой диспетчер
источник

ФШ

Футуристичный Школьн... in Yii Framework 2
Tagil Steel
Есть такая вещь в ООП - множественное наследование. В принципе, она помогает делать код стройнее и понятнее.
Нативный способ иммитации множественного наследования - это трейты. С большими ограничениями.
А способ Yii - это поведения, подписывающиеся на события. Ограничений значительно меньше, но тормозов больше.
<zanuda_mode>
Альтернативой множественного наследования являются интерфейсы.
Трейты это реализация паттерна mixin
</zanuda_mode>
источник

ПГ

Павел Грибалёв... in Yii Framework 2
Oleg Kuzmenko
Вот самое неприятное — так это то, что в Йии надо пилить свой диспетчер
Можешь не писать) Можно использовать юии эвенты, можно написать, а можно взять пакет сммфони EventDispatcher))
источник

В

Витя in Yii Framework 2
привет всем )) 0
источник

OK

Oleg Kuzmenko in Yii Framework 2
Павел Грибалёв
Можешь не писать) Можно использовать юии эвенты, можно написать, а можно взять пакет сммфони EventDispatcher))
Та я в результате напилил свои хэндлеры для соответствующих классов событий, но все равно не в восторге от того, что я вижу
источник