Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
!!! FEATURE: Event Publisher #256
Introduces the notion of Event Publishers that are triggered whenever events are committed to the Event Store.
This makes the mechanism much more extensible and is a preparation for standalone use.
This is a breaking change because there is no
Neos: EventSourcing: EventStore: stores: 'default': storage: 'Neos\EventSourcing\EventStore\Storage\Doctrine\DoctrineEventStorage' listeners: '.*': true
But the new best practice is to define a (namespaced) Event Store for the main package / distribution that defines the events and listeners (see README).
Neos: EventSourcing: EventListener: listeners: 'Some\Package\SomeCustomListener': eventStore: 'some_custom_store' 'Some\Package\SomeOtherListener': eventStore: 'some_custom_store'
Neos: EventSourcing: EventStore: stores: 'some_custom_store': listeners: 'Some\Package\Some(Custom|Other)Listener': true
albe left a comment
Generally approve. Left some comments. I did like the "EventListenerTrigger" a more fitting name than "eventPublisher" - but, well, guess a "publisher" is a better known concept (though a tiny bit misleading in this case).
bwaidelich left a comment
@albe thanks again for your feedback!
In the framework we use the publisher only to trigger event listeners. But it could be used for all kinds of things on top of that (send out websocket events, flush caches, ...).
I took the name from Greg Youngs "Simple CQRS example"