-
Couldn't load subscription status.
- Fork 1
Example of using $container for $dispatcher injection #12
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
base: plugin-deprecation-registerListeners
Are you sure you want to change the base?
Example of using $container for $dispatcher injection #12
Conversation
|
This can work indeed. But, booting the extension in to your own container can be a nice feature. |
|
which part would you say is hacky? parts which are b/c things or providing the container for booting the component? |
|
This part, which is b/c thing: joomla-cms/libraries/src/Plugin/PluginHelper.php Lines 234 to 240 in 4f2f071
But can work. |
|
That's actually not a b/c thing ;-) There is no other possibility to provide the dispatcher to plugin. Because setDispatcher be called (here) and $dispatcher in the CMSPlugin::constructor has been removed. |
|
I somehow ignored that you changed the boot method signature, sure it is b/c 😄 |
|
I have another idea. // Regular
$app->getExtensionManager()
->bootPlugin($name, $type);
// With custom container
$app->getExtensionManager()
->setContainer($container->createChild()->set(DispatcherInterface::class, $dispatcher))
->bootPlugin($name, $type);This can be fully backward compatible, and provide much more flexibility. What do you think? upd. hmhm, but in this way we will have cashing issue, also with your suggestion in this PR |
|
yes I already found out, or better allon pointed me to the static cache in the boot method, which is not really useful in my opinion because it prevent you booting the same component in 2 different settings... maybe it can be extended on the container hash... not sure anyway your suggestion looks a way better then mine if it works. |
No description provided.