PSR-11 and Configuration

[Westin Shafer]

Hey Guys,

After having built quite a few packages to integrate services into PSR-11 containers, I have to say PSR-11 has made this incredibly nice and IMO has solved a lot of issues building libraries that just work across different frameworks.   That said, there is still one issue that has hit me on each of these libraries getting configuration out of the different containers.   As each framework stores configuration in a different way there seems to be no uniform way to retrieve it.  This leads to unnecessary implementation specific code.

Here's an example of what I mean.

        // Symfony config is parameters. //
        if (method_exists($container, 'getParameter')
            && method_exists($container, 'hasParameter')
            && $container->hasParameter('my-key')
        ) {
            return $container->getParameter('my-key');
        }

        // Zend uses config key
        if ($container->has('config')) {
            return $container->get('config')['my-key'];
        }

        // Slim Config comes from "settings"
        if ($container->has('settings')) {
            return $container->get('settings')['my-key'];
        }

As you can see, this is one area where PSR-11 could use some improvement.   I did see a thread dated few years ago where someone had started a conversation to address this.   Has there been any movement or other conversations about this?   If not, is there anything I can do to help move this conversation forward?


Thanks in advance,
Westin Shafer

[Woody Gilk]

Having a PSR that defines a configuration interface would be
fantastic. It should not replace PSR-11 though. Configuration and
containers are completely different things, despite how they might be
conflated in various frameworks.
--
Woody Gilk
http://about.me/shadowhand

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/60bb4c3a-ec94-4081-82d0-2a9f683dcfca%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alessandro Lai]

I completely agree with that. This could be a completely separated PSR that produces an interface for getting configuration values; if frameworks decide to implement both this and PSR-11 interfaces on the same class it's an implementation detail!

> email to php-fig+unsubscribe@googlegroups.com.

[Matthew Weier O'Phinney]

On Mon, Feb 12, 2018 at 7:07 PM, Westin Shafer <wsh...@gmail.com> wrote:

> That said, there is still one issue that has hit me on each of
> these libraries getting configuration out of the different containers. As
> each framework stores configuration in a different way there seems to be no
> uniform way to retrieve it. This leads to unnecessary implementation
> specific code.

<snip>

> As you can see, this is one area where PSR-11 could use some improvement.
> I did see a thread dated few years ago where someone had started a
> conversation to address this. Has there been any movement or other
> conversations about this? If not, is there anything I can do to help move
> this conversation forward?

There has been some work on it in the container-interop group; the
project is called "service providers":

- https://github.com/container-interop/service-provider

There's not been a ton of movement on it, but the idea is pretty solid.

In parallel, the ZF community has been working on a number of
"zend-{container type}-config" projects that are attempting to
identify common configuration features of many containers, and provide
a translation layer around them. So far, we've identified:

- aliases (though these could likely be addressed by a specialized factory type)
- invokables (constructor-less classes; could also be addressed by a
specialized factory type)
- factories
- delegators/decorators (these are similar to the "extensions"
functionality of the service-provider project)
- fallbacks/abstract factories (these produce an instance for any
given service name)

I'm involved with the container-interop team, but haven't had time to
drive any discussions recently. I'm sure I speak for the others when I
say your feedback and input would be welcome!

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Westin Shafer]

Hi Matthew,

Thanks for the info.  I had took some time to read the docs and I hope you don't take this the wrong way, but it seems to me you guys are over thinking the problem.   I think PSR-11 ended up working out great for this.   To build a cross framework service is now very easy, and asking a developer to register your libraries factory with what ever framework or container they are using doesn't seem like a big deal.  The only issue left to really achieve what you guys attempting is simply getting at the applications configuration.  It's the frameworks/containers config that's a bit tricky to get to.

Alias's, Invokables, delegators/decorators, abstract factories really seem like implementation details to me.  These are huge selling features of Zend Service Manager and why one might choose to use it.  On the flip side, not having these features and the extra code that go with it, are huge selling points of Pimple and Slim.  So far knowing that I don't have these features everywhere has not hindered me from building modules that span across frameworks.  If you ask me, the problems you're trying to solve here were best addressed by the container-interops "container within a container" as it left  implementations alone and gave the users a middle layer they could keep long enough to migrate away from a particular container.  I thought this was a great idea.  Unfortunately that was dropped in psr-11.

Going back to Woody and Alessandro comments, it seems to me a simple interface like say, ConfigProviderInterface with a simple method of getConfig() and one interface for the config like ConfigInterface with methods like has($key) and get($key) would solve the issue of having services that you can use across all the compliant frameworks and containers.

I don't think registering a factory and adding a little config with your container of choice is too much to ask a developer to do, it's just hard to get at the config as a generic service.

Westin Shafer