- Notifications
You must be signed in to change notification settings - Fork90
FixedFormAnnotationBuilderFactory::injectFactory() for zend-servicemanager v2#235
FixedFormAnnotationBuilderFactory::injectFactory() for zend-servicemanager v2#235
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…emanager v2The 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 thecorrect 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 |
| ) { | ||
| if ($formElementManagerinstanceof FormElementManagerV2Polyfill) { | ||
| $formElementManager->injectFactory($annotationBuilder,$container); | ||
| $formElementManager->injectFactory($annotationBuilder,$formElementManager); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Why would the formElementManager inject itself? I still dont get the meaning of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The v3 implementation is therefore passing the real container.
You totally irritated me on this now 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 managersServiceLocatorAware, 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 anotherController in aControllerFactory 😁.
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