Open bakura10 opened 9 years ago
@bakura10 Please take a look at the interop-config library and the PSR config proposal. I think this could help to define a good config structure for the factory.
I'm not sure, but if you want to merge listeners from another config file for the onDispatch event, should not the event name onDispatch be the array key and listener an array? But the problem with lazy listeners still exists.
return [
'event_manager' => [
'onDispatch' => [
'listeners' => [],
]
],
];
The event manager may require multiple discrete instances as well, which makes having listener configuration for a single EM instance far less useful.
If anything, I think we need a factory for generating a set of listeners from configuration, which would generate an aggregate to attach to an EM instance; delegator factories could then use this to seed instances intended for specific targets.
Additionally, a factory for creating and seeding the shared event manager could be useful. On Sep 26, 2015 4:02 PM, "Sandro Keil" notifications@github.com wrote:
@bakura10 https://github.com/bakura10 Please take a look at the interop-config https://github.com/sandrokeil/interop-config library and the PSR config proposal https://github.com/php-fig/fig-standards/pull/620. I think this could help to define a good config structure for the factory.
I'm not sure, but if you want to merge listeners from another config file for the onDispatch event, should not the event name onDispatch be the array key and listener an array? But the problem with lazy listeners still exists.
return [ 'event_manager' => [ 'onDispatch' => [ 'listeners' => [], ] ],];
— Reply to this email directly or view it on GitHub https://github.com/zendframework/zend-eventmanager/issues/9#issuecomment-143495584 .
With interop-config factories for specific EM instances can easily be created. Just provide a AbstractEventManagerFactory
that implements the interfaces provided by interop-config, use the ConfigurationTrait and mark HasContainerId::containerId as abstract so that extending factories need to provide a unique container id for specific EM instances. This way you would be able to configure listeners per Instance but have the attaching logic in a central place within the AbstractEventManagerFactory
.
Just my 2c
This repository has been closed and moved to laminas/laminas-eventmanager; a new issue has been opened at https://github.com/laminas/laminas-eventmanager/issues/9.
Hi,
Because of Zend\Expressive and the possible removal of module manager, it won't be possible for each "module" to attach their own listeners. Instead, everything should be handled with config files, that allow easier merging.
Starting from v3, it should have a default EventManagerFactory that would be able to read config from an interop container and create a full EVM.
It should accept a key "event_manager", read from a config service.
I'm not sure of how the config should be made so that we can support lazy, non-lazy...