[EventDispatcher] Add DefaultPriorityInterface to allow setting priority for autowired listener, without a need to register it as a service in configs.
#35444
Conversation
…ority for autowired listener, without a need to register it as a service.
fre5h
changed the title
DefaultPriorityInterface to allow setting priority for autowired listener, without a need to register it as a service.DefaultPriorityInterface to allow setting priority for autowired listener, without a need to register it as a service in configs..
fre5h
changed the title
DefaultPriorityInterface to allow setting priority for autowired listener, without a need to register it as a service in configs..DefaultPriorityInterface to allow setting priority for autowired listener, without a need to register it as a service in configs.
|
Hello' Thanks for this proposal. But I fail to see why we should support another way to register a listener with priority where everything is already supporter with subscribers |
|
You mean, that if listener implemented with In my opinion On my project I was faced with a situation when each listener for the family of events (lets say events related to order entity) has its own unique dependencies and priority. Grouping it all together in subsriber will broke the single responsibility principle, because a lot of different business logic and dependencies in one class. I decided to divide code into small independent listeners with a new cool feature of services:
_defaults:
autowire: true
App\EventListener\:
resource: '../../src/EventListener/'
tags:
- 'kernel.event_listener'And everything was great until I needed to set custom priority. Right now I have configs for all listeners with custom priority in my I agree, that adding the |
|
IMHO listeners are pure (domain) callables. Adding DefaultPriorityInterface adds coupling to the framework. For these cases (framework listeners) using EventSubscriberInterface is fine, and more easy: https://www.tomasvotruba.com/blog/2019/07/22/how-to-convert-listeners-to-subscribers-and-reduce-your-configs/ At this point, for listeners, i think App\EventListener\:
resource: '../../src/EventListener/'
tags: [kernel.event_listener]is the final form, which cannot be further simplified. |
|
@ro0NL Thank you for your answer 👍 |
|
And if you use autowiring and autoconfiguration you can have one small subscriber per file that respect SRP and also support for priority |
|
I agree with @lyrixx, |
|
OK, then I close it |
5 participants
Thanks to the autowiring, we can easily add new services without a need to register them in configs.
We can create an EventListener class that has a method
__invokethat receives the event of some class and thanks to the autowiring we don't need to register this listener as service in configs.By default all listeners have priority 0. But when we need to set a custom priority, we have to add a config for listener and set the priority there. (If listener implements
EventSubscriberInterfacethen it is possible to set priority ingetSubscribedEventsmethod. But I talk about listeners as closures)If you have a lot of listeners with custom priority you have to write configs for all of them. So you cannot use easily autowiring in this case.
I propose to add a
DefaultPriorityInterfacewith a static methodgetDefaultPriorityand set the default priority inside the class, so you don't have to put priority into config files. And your config files will be smaller and cleaner.My request doesn't break BC, because you can still add
priorityas config parameter for listener.So as a result config file with autowiring:
Listener with a custom priority:
In the case when listener implements
DefaultPriorityInterfaceand haspriorityargument in config, thepriorityfrom config will be used. In this case it is 99