You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR removes ModuleManager from MVC, removes dependency on its ServiceListener and changes factories for various managers that depended on it to pull config from container instead. Container is now expected to be configured before application is created.
Main container is no longer required to be ServiceManager. To accommodate that change, EventManager initializer is removed. Should users need it, they should implement it in userland code but preferable approach, however, is to inject dependencies explicitly.
Update: Bootstrapper introduced by this PR was dropped as it provided little value, considering conceptual order of early Application lifecycle stages.
Introduced new ApplicationListenerProvider service which is a listener aggregate that provides default listeners and pulls list of listeners from main config: $config[Zend\Mvc\Application::class]['listeners'] = []. Entries are either a container id string or instance of listener aggregate interface. This is one of the parts to be replaced as part of eventual migration to PSR event manager.
Application::init() helper method is dropped. zend-mvc application setup is expected to resemble that of zend-expressive:
Back in the time, module manager was introduced to provide basic packaging support, module loading, autoloading, config loading and merging. Number of important things happened since then.
Composer emerged and became a standard package manager in php world. It solved packaging and autoloading needs. Module is no longer need to be registered with zend-service manager, located and loaded in order to register autoloading rules it provides.
No longer constrained by autoloading, dedicated ConfigAggregator was able to handle config loading and merging in a simple and clean way.
Since service configuration is available before container is created, Zend\ModuleManager\Listener\ServiceListener for various plugin managers is obsoleted and could be replaced by regular factories. ( This PR did exactly that, look at eg Zend\Mvc\Container\ControllerManagerFactory)
Second most used module feature is Module::onBootstrap(). Just a convenience method for providing listener for zend-mvc bootstrap event. Zend-modulemanager registered those during module loading. Now, with config available early, factories for Zend\Mvc\Application could pull from config and register a list of extra listener aggregates ($config[Zend\Mvc\Application::class]['listeners'] = []). Listener aggregates themselves could be managed by container with all the power and flexibility that gives.
Module can be closely replicated with just a config provider:
Note that this PR provides no convenience wrapper for that use case at this time since upcoming PSR-14 for Event Manager is expected to be accepted before 4.0 is ready.
Overall, dropping module manager from zend-mvc greatly simplifies whole zend-mvc application setup and brings zend-mvc more in line with newer zend-expressive and ConfigProviders usage in Zend Framework components.
TODO
Replace ServiceListener as a configurator for plugin managers with factories pulling config from config service
Drop module manager
Provide alternative way to configure and bootstrap application from config
Add ConfigProvider
Move all container configuration to ConfigProvider
Replace main ServiceManager container with PSR-11 ContainerInterface
Current documentation is quite dated. I think I will leave out documentation update in this PR for the major docs update when more of the significant changes for next are done and merged.
This PR removes ModuleManager from MVC, removes dependency on its ServiceListener and changes factories for various managers that depended on it to pull config from container instead. Container is now expected to be configured before application is created.
Main container is no longer required to be ServiceManager. To accommodate that change, EventManager initializer is removed. Should users need it, they should implement it in userland code but preferable approach, however, is to inject dependencies explicitly.
Update: Bootstrapper introduced by this PR was dropped as it provided little value, considering conceptual order of early Application lifecycle stages.
Introduced new ApplicationListenerProvider service which is a listener aggregate that provides default listeners and pulls list of listeners from main config:
$config[Zend\Mvc\Application::class]['listeners'] = []
. Entries are either a container id string or instance of listener aggregate interface. This is one of the parts to be replaced as part of eventual migration to PSR event manager.Application::init()
helper method is dropped. zend-mvc application setup is expected to resemble that of zend-expressive:Back in the time, module manager was introduced to provide basic packaging support, module loading, autoloading, config loading and merging. Number of important things happened since then.
Composer emerged and became a standard package manager in php world. It solved packaging and autoloading needs. Module is no longer need to be registered with zend-service manager, located and loaded in order to register autoloading rules it provides.
No longer constrained by autoloading, dedicated ConfigAggregator was able to handle config loading and merging in a simple and clean way.
Since service configuration is available before container is created,
Zend\ModuleManager\Listener\ServiceListener
for various plugin managers is obsoleted and could be replaced by regular factories. ( This PR did exactly that, look at egZend\Mvc\Container\ControllerManagerFactory
)Second most used module feature is
Module::onBootstrap()
. Just a convenience method for providing listener for zend-mvcbootstrap
event. Zend-modulemanager registered those during module loading. Now, with config available early, factories forZend\Mvc\Application
could pull from config and register a list of extra listener aggregates ($config[Zend\Mvc\Application::class]['listeners'] = []
). Listener aggregates themselves could be managed by container with all the power and flexibility that gives.Module can be closely replicated with just a config provider:
Note that this PR provides no convenience wrapper for that use case at this time since upcoming PSR-14 for Event Manager is expected to be accepted before 4.0 is ready.
Overall, dropping module manager from zend-mvc greatly simplifies whole zend-mvc application setup and brings zend-mvc more in line with newer zend-expressive and ConfigProviders usage in Zend Framework components.
TODO
config
serviceOriginally posted by @Xerkus at zendframework/zend-mvc#273
The text was updated successfully, but these errors were encountered: