Currently it is only possible to configure the StorageAdapterFactory using delegators such as laminas-cache-storage-adapter-memory/AdapterPluginManagerDelegatorFactory.php at 2.1.x · laminas/laminas-cache-storage-adapter-memory · GitHub. I wanted to understand why this Service Manager works like that and not like say the InputFilterManager where you can register all services using the config. Is this something you’d consider?
Hello and welcome to our forums!
You can configure what you want but maybe you can first describe what your goal is and where the problem lies in achieving it.
I had to write a custom storage adapter for my company and got a bit surprised in how I had to inject it in the StorageAdapterFactory. It is working now so no real reason to change it beside to make it work like other service managers.
This is more a “I want to understand why this was done differently” kind of issue.
Please see the release notes of version 2.12.0 of laminas-cache for some backgrounds:
The main background is the splitting of the adapters into individual components.
Thank you @froschdesign !
I did not mention why I’ve chosen delegator factories over a recursively merged plugin manager configuration within the projects $config
.
Every other service manager laminas provides does have a dedicated configuration key (such as validators
) but the laminas-cache
component never had such configuration key.
One of the main benefits of having delegators is that due to the usage of ServiceManager#configure
, we do have type-safety on a static-analysis level due to the parameter type declaration of the $config
argument:
(snippet)
/**
* @psalm-param ServiceManagerConfiguration $config
*/
So whenever a delegator is used, type-safety can be achieved before executing any LoC. If you just add some random array keys to (for example) your ConfigProvider::__invoke
, you might probably not have that advantage.
I am open for an RFC on github where we can discuss if we should want to add a new $config
array key for the AdapterPluginManager
(and the other plugin manager* within the laminas-cache
component).
I understand that there might be minor performance reasons on why one might want to have a cached config instead of delegators which need to be instantiated + invoked to configure the plugin managers.