Comments (9)
The container by definition primarily deals with services as dependencies, it is intended that a class will be given priority.
Take a look here if you want to store values, although I wouldn't recommend it as good practice.
https://github.com/thephpleague/container/blob/master/src/Argument/RawArgument.php
from container.
Would be curious to hear more about why you consider it bad practice to store parameters in the container as this is a standard practice in the symfony community at least.
Are you indicating that
$container->add('my_string_param', new RawArgument('myrawvalue'));
would work? Argument makes some sense in the context of a service definition but not in terms of registering a simple value parameter.
from container.
Just SRP really, a container is in essence a service registry. Values such
as your db connection parameters really should be handled by the
environment.
The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.
The purpose of the container is to define your dependency map and to wire
those dependencies together.
On Wed, 25 May 2016 17:54 Ben Glassman, [email protected] wrote:
Would be curious to hear more about why you consider it bad practice to
store parameters in the container as this is a standard practice in the
symfony community at least.Are you indicating that
$container->add('my_string_param', new RawArgument('myrawvalue'));
would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.—
You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub
#106 (comment)
from container.
I take your point that it is best practice to store sensitive data in
environment variables but there are other values you might store in a
container that are not sensitive or environment-specific. Instantiating
services often requires non-instance values to be injected into
constructors or setter methods so I believe that it does not violate SRP to
have a container be able to store those types of values that are used for
the purpose of instantiating services.
It seems this is not a feature that container will support but I do think
its something that has clear utility as evidenced by its presence in many
other container implementations (symfony, pimple, etc.).
It may be worth including some mention that there is no plan to support
this in the documentation and a recommendation on an alternate approach
since I think it is likely many people trying to use this package may
wonder how they are supposed to handle parameters especially if they are
coming from another container that supports them.
For my purposes I will just be using pimple as it supports this use case.
On Wed, May 25, 2016 at 1:14 PM, Phil Bennett [email protected]
wrote:
Just SRP really, a container is in essence a service registry. Values such
as your db connection parameters really should be handled by the
environment.The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.The purpose of the container is to define your dependency map and to wire
those dependencies together.On Wed, 25 May 2016 17:54 Ben Glassman, [email protected] wrote:
Would be curious to hear more about why you consider it bad practice to
store parameters in the container as this is a standard practice in the
symfony community at least.Are you indicating that
$container->add('my_string_param', new RawArgument('myrawvalue'));
would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.—
You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub
<
#106 (comment)—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#106 (comment)
from container.
If you intend to share configuration values, have a look at https://github.com/tomphp/config-service-provider - we're using it in production and it works well. Maybe it helps you, too?
from container.
Parameters can be handled either by defining them when you define the
service or by passing them at runtime as a second argument to the get
method. You can even use the raw argument approach I mentioned before and
passing the name of that definition to your service, parameters and
arguments are just that and are handled as such. Services have to take
priority though. Another optioned would be to still store your raw values,
but give them an alias that does not clash with a class name.
On Wed, 25 May 2016 18:27 Ben Glassman, [email protected] wrote:
I take your point that it is best practice to store sensitive data in
environment variables but there are other values you might store in a
container that are not sensitive or environment-specific. Instantiating
services often requires non-instance values to be injected into
constructors or setter methods so I believe that it does not violate SRP
to
have a container be able to store those types of values that are used for
the purpose of instantiating services.It seems this is not a feature that container will support but I do think
its something that has clear utility as evidenced by its presence in many
other container implementations (symfony, pimple, etc.).It may be worth including some mention that there is no plan to support
this in the documentation and a recommendation on an alternate approach
since I think it is likely many people trying to use this package may
wonder how they are supposed to handle parameters especially if they are
coming from another container that supports them.For my purposes I will just be using pimple as it supports this use case.
On Wed, May 25, 2016 at 1:14 PM, Phil Bennett [email protected]
wrote:Just SRP really, a container is in essence a service registry. Values
such
as your db connection parameters really should be handled by the
environment.The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.The purpose of the container is to define your dependency map and to
wire
those dependencies together.On Wed, 25 May 2016 17:54 Ben Glassman, [email protected]
wrote:Would be curious to hear more about why you consider it bad practice
to
store parameters in the container as this is a standard practice in
the
symfony community at least.Are you indicating that
$container->add('my_string_param', new RawArgument('myrawvalue'));
would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.—
You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub
<—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
<
https://github.com/thephpleague/container/issues/106#issuecomment-221641258>—
You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub
#106 (comment)
from container.
I think the issue I was coming across is that its actually the value that
was clashing with a class name. Prefixing the parameters with "config."
didnt help because the second argument had class_exists() run on it which
in this case it was 'db' and therefore it thought it was a class. Parameter
names are easy to control but values are not.
On Wed, May 25, 2016 at 1:42 PM, Phil Bennett [email protected]
wrote:
Parameters can be handled either by defining them when you define the
service or by passing them at runtime as a second argument to the get
method. You can even use the raw argument approach I mentioned before and
passing the name of that definition to your service, parameters and
arguments are just that and are handled as such. Services have to take
priority though. Another optioned would be to still store your raw values,
but give them an alias that does not clash with a class name.On Wed, 25 May 2016 18:27 Ben Glassman, [email protected] wrote:
I take your point that it is best practice to store sensitive data in
environment variables but there are other values you might store in a
container that are not sensitive or environment-specific. Instantiating
services often requires non-instance values to be injected into
constructors or setter methods so I believe that it does not violate SRP
to
have a container be able to store those types of values that are used forthe purpose of instantiating services.
It seems this is not a feature that container will support but I do think
its something that has clear utility as evidenced by its presence in many
other container implementations (symfony, pimple, etc.).It may be worth including some mention that there is no plan to support
this in the documentation and a recommendation on an alternate approach
since I think it is likely many people trying to use this package may
wonder how they are supposed to handle parameters especially if they are
coming from another container that supports them.For my purposes I will just be using pimple as it supports this use case.
On Wed, May 25, 2016 at 1:14 PM, Phil Bennett [email protected]
wrote:Just SRP really, a container is in essence a service registry. Values
such
as your db connection parameters really should be handled by the
environment.The only time I can see storing raw values being useful is if you were
using it as a service locater which is considered an anti pattern.The purpose of the container is to define your dependency map and to
wire
those dependencies together.On Wed, 25 May 2016 17:54 Ben Glassman, [email protected]
wrote:Would be curious to hear more about why you consider it bad practice
to
store parameters in the container as this is a standard practice in
the
symfony community at least.Are you indicating that
$container->add('my_string_param', new RawArgument('myrawvalue'));
would work? Argument makes some sense in the context of a service
definition but not in terms of registering a simple value parameter.—
You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub
<—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
<—
You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub
<
#106 (comment)—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#106 (comment)
from container.
The easiest way around this is as follows.
$container->add('key', function () {
return 'value';
});
from container.
Realized that, so I opened tomphp/container-configurator#21.
As an alternative to what @philipobenito suggested, how about
use League\Container\Argument\RawArgument;
class StringArgument extends RawArgumentInterface
{
public function __toString()
{
return $this->value;
}
}
and then
$container->add('key', new StringArgument('value'));
from container.
Related Issues (20)
- References are unallowed HOT 1
- Can't override a definition.
- Setting concrete does not reset arguments. HOT 4
- [2.x] Add support for PHP 8 HOT 2
- Extends causing an infinite loop HOT 1
- Inconsistent Behavior HOT 12
- Question: Possible to use tags in Service Providers? HOT 3
- Fatal error: incompatible declaration of get method against PSR interface, in some PHP versions HOT 5
- Returning from an inflector HOT 7
- Support for non-object concrete values HOT 3
- Question: How to "inflect once" for shared services? HOT 13
- Preceeding slash confusing fully qualified class names HOT 1
- Extends causing an infinite loop HOT 2
- Question: Can Container Change an Alias? HOT 1
- Huge performance hits when having a bigger application with a lot of service definitions HOT 6
- How swap added definition HOT 1
- Auto wiring a shared dependency HOT 1
- Infinate loop in resolving non-existant class HOT 1
- Question: How to achieve autowiring inside the service provider? HOT 1
- Is this package still maintained? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from container.