zendframework/zf2 — pull request #1550 by weierophinney (2012-06-22 05:50:05+00:00)
Title: Service manager as plugin broker

In this PR, I've refactored all components that use a plugin broker (with the exception of AMF, which is currently unstable anyways) to instead compose component-specific service managers.

This introduces `Zend\ServiceManager\AbstractPluginManager`, as well as a few additions and fixes to the `ServiceManager` implementation itself. `AbstractPluginManager` accomplishes the following:

* Allows passing class names directly (a feature of the old plugin broker solution)
* Allows passing options to `get()`: `get($name, $options)`. Options are by default passed directly to the constructor.
* Allows marking the container to either share or not share instances by default, instead of requiring passing the `$shared` flag when calling one of the set/add methods. (This is actually a new feature of the `ServiceManager`, but only currently used in plugin manager implementations.)
* Registers an initializer, `validatePlugin()`, at the top of the initializer stack. This allows validating that a plugin satisfies context-specific criteria.
* Ability to peer on another service manager; if plugins cannot be retrieved from the plugin manager, but a peer is set, it will attempt to retrieve via the peer. By default, I've specified that any plugin manager managed by the MVC service manager configuration will peer off the application service manager. This makes adding plugins a trivial matter -- simply define them as services. (This functionality is technically part of the `ServiceManager` implementation.

Benefits of this include:

* Keeping all plugin information in one place, instead of across multiple classes. The plugin broker solution required both the broker as well as a loader class for each plugin type. Now both are combined in a single solution.
* Overall, 50% less code.
* More flexibility in attaching plugins: attach instances, factories, abstract factories, etc. Or attach them to the application SM instance, and the plugin manager will fetch from there.
* One less API to learn. Technically, we can remove the Plugin Broker and PluginClassLocator solutions at this time.

All code has been tested, though I have not completely tested with the skeleton application at this time. When possible, I have retained configuration keys for the MVC services in order to retain compatibility with the previous betas.