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!

Il giorno martedì 13 febbraio 2018 02:54:20 UTC+1, Woody Gilk ha scritto:
>
> 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 
>
>
> On Mon, Feb 12, 2018 at 7:07 PM, Westin Shafer <wsha...@gmail.com> wrote: 
> > 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 
> > 
> > -- 
> > 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+unsubscr...@googlegroups.com. 
> > To post to this group, send email to php-fig@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. 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d3932819-743a-4033-9ea5-c9e69f892984%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to