Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a factory for EVM #9

Open
weierophinney opened this issue Dec 31, 2019 · 5 comments
Open

Add a factory for EVM #9

weierophinney opened this issue Dec 31, 2019 · 5 comments

Comments

@weierophinney
Copy link
Member

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.

return [
   'event_manager' => [
     [
         'event_name' => 'onDispatch',
         'listener'         => function() {},
         'is_lazy'          => true
     ]
  ],

  'shared_event_manager' => [ ?? ]
];

I'm not sure of how the config should be made so that we can support lazy, non-lazy...


Originally posted by @bakura10 at zendframework/zend-eventmanager#9

@weierophinney
Copy link
Member Author

@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' => [],
       ]
  ],
];

Originally posted by @sandrokeil at zendframework/zend-eventmanager#9 (comment)

@weierophinney
Copy link
Member Author

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" [email protected] 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
php-fig/fig-standards#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
zendframework/zend-eventmanager#9 (comment)
.


Originally posted by @weierophinney at zendframework/zend-eventmanager#9 (comment)

@weierophinney
Copy link
Member Author

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


Originally posted by @codeliner at zendframework/zend-eventmanager#9 (comment)

@devlubinets
Copy link

devlubinets commented Feb 19, 2024

Is it actuall? @weierophinney @froschdesign

@weierophinney
Copy link
Member Author

@devlubinets Yes, it's still open. There haven't been many requests for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants