Fixed FormAnnotationBuilderFactory::injectFactory() for zend-servicemanager v2
#235
Conversation
…emanager v2 The patch introduced for 2.7.11 was incorrect in that it was passing the `$container` argument, and not the `$formElementManager` argument, to `$formElementManager->injectFactory()`. This patch updates it to use the correct value, and fixes the related test expectation as well.
|
@boesing — You can test this as follows.
Let me know if this works for you. |
|
This works for me. Thanks a lot! I am still confused about that self injecting |
| @@ -96,7 +96,7 @@ private function injectFactory( | |||
| AnnotationBuilder $annotationBuilder | |||
| ) { | |||
| if ($formElementManager instanceof FormElementManagerV2Polyfill) { | |||
| $formElementManager->injectFactory($annotationBuilder, $container); | |||
| $formElementManager->injectFactory($annotationBuilder, $formElementManager); | |||
There was a problem hiding this comment.
Why would the formElementManager inject itself? I still dont get the meaning of this.
There was a problem hiding this comment.
The v3 implementation is therefore passing the real container.
You totally irritated me on this now 🙈
There was a problem hiding this comment.
It's a difference in how plugin managers work between version 2 and version 3.
In version 2, plugin managers pass themselves as the $container/$serviceLocator argument to factories and initiailizers. The idea at the time was to keep the plugin managers scoped; they would know nothing about the application-level services. However, we quickly realized this was problematic: most of the time, particularly with custom plugins, you need to access application-level services, such as the database connection, repositories, etc. So we made the plugin managers ServiceLocatorAware, so they would be injected with the parent (application) plugin manager, allowing plugin factories and initializers access to those services.
When we refactored the component for v3, we took this into consideration, and decided that plugin managers should be injected with the parent "context" (usually the application-level service manager), and that the parent context should be passed to plugin factories and initializers. This reduces the amount of boilerplate necessary for the vast majority of these classes, as it addresses the most typical use case.
Obviously, however, that has also meant some interesting migration issues when trying to provide both forwards compatibility with v3 implementations, and backwards compatibility with v2. You just stumbled upon one of the worst. 😁
There was a problem hiding this comment.
When we refactored the component for v3, we took this into consideration, and decided that plugin managers should be injected with the parent "context" (usually the application-level service manager), and that the parent context should be passed to plugin factories and initializers. This reduces the amount of boilerplate necessary for the vast majority of these classes, as it addresses the most typical use case.
Makes sense, I dont think that anyone wants create another Controller in a ControllerFactory 😁.
Thanks for your patience and for those great insights of what was changed, e.g.
|
Released as 2.7.12. |
The patch introduced for 2.7.11 was incorrect in that it was passing the
$containerargument, and not the$formElementManagerargument, to$formElementManager->injectFactory(). This patch updates it to use the correct value, and fixes the related test expectation as well.cc @boesing