Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DI][FrameworkBundle] Add PSR-11 "ContainerBag" to access parameters as-a-service #25288

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

Merged
merged 2 commits into from
Dec 8, 2017

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Dec 3, 2017

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #17160
License MIT
Doc PR -

There is one thing that prevents us from not injecting the container: access to the parameter bag.
This PR fixes this limitation by providing a PSR-11 ContainerBagInterface + related implementation, and wiring it as a service that ppl can then also autowire using the new interface as a type hint, or ParameterBagInterface.

Needed to complete e.g. #24738

/**
* @author Nicolas Grekas <[email protected]>
*/
interface ContainerBagInterface extends ContainerInterface
Copy link
Contributor

@ro0NL ro0NL Dec 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we move this one namespace up? is typehinting SF\ContainerBagInterface instead of SF\ParamaterBagInterface really worth it? What about a ContainerParameterBag implem to enable typehinting ParamaterBagInterface?

in general #24738 needs ParamaterBagInterface::resolveValue() actually

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we move this one namespace up?

that's a parameter bag, should be in the namespace to me

is typehinting SF\ContainerBagInterface instead of SF\ParamaterBagInterface really worth it?

yes: the new interface is more tailored than, the existing one, better for autosuggestion by IDEs

What about a ContainerParameterBag implem to enable typehinting ParamaterBagInterface?

isn't that already what the new ContainerBag provides?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the new interface is more tailored than, the existing one, better for autosuggestion by IDEs

Yeah but why favor ContainerBagInterface over ParamaterBagInterface from the same package/namespace? Is it to provide 2 different PSR containers? Are we "hacking" autowiring?

class ContainerParameterBag implements ParamBagInterface, PSR\ContainerInterface
{ }

would do?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's say you have ContainerBagInterface $bag type-hint.
typing $bag-> the IDE will suggest you with "get", "has" and "all".
if we do what you suggest, the IDE will also suggest all the other methods inherited from ParamaterBagInterface, which, if used, will throw.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I was thinking you'd prefer ContainerInterface $bag actually, which troubles autowiring when you need $container also. So we add this interface.. for DX. That's OK i guess :-)

Copy link
Contributor

@ro0NL ro0NL Dec 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ContainerBagInterface::resolveValue would be useful? never mind, you'd typehint ParamaterBagInterface then i guess.

Copy link
Member Author

@nicolas-grekas nicolas-grekas Dec 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ContainerBagInterface::resolveValue would be useful?

not for this PR
I changed my mind during the night, here it is, trivial to add :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait... do the point of this interface is just for DX? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything we do in a framework that is not for DX?
Anyway, "for DX" is not a technical thing. Here is the technical outcome: the interface is to declare a contract you want to adhere to: you explicitly state that you're going to need read-only access to the bag. That's the purpose of the interface.

@@ -110,6 +112,12 @@ public function load(array $configs, ContainerBuilder $container)
$loader->load('services.xml');
$loader->load('fragment_renderer.xml');

if (!interface_exists(ContainerBagInterface::class)) {
$container->removeDefinition('parameter_bag');
$container->removeAlias(ContainerBagInterface);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing ::class, same below

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed :)

@@ -5,6 +5,7 @@ CHANGELOG
-----

* added support for variadics in named arguments
* added PSR-11 `ContainerBagInterface` and its `ContainerBag` implementation to access parameters as-as-service
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo as-a

@nicolas-grekas nicolas-grekas force-pushed the di-container-bag branch 2 times, most recently from fb6e28e to c993ebb Compare December 3, 2017 17:05
*
* @return array An array of parameters
*/
public function all();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return type declaration?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not possible: would make the interface incompatible with ParameterBagInterface.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm too late but, is this true?
https://3v4l.org/NPigR

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it isn't.

/**
* @author Nicolas Grekas <[email protected]>
*/
class ContainerBag extends FrozenParameterBag implements ContainerBagInterface
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could probably be made final, I see no reason to extend this rather than implementing the interface.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't make classes final "by default", that's not the framework's policy.

Copy link
Contributor

@TomasVotruba TomasVotruba Dec 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's good idea. Could that change for new classes?
Like adding scalar type is?

Copy link
Contributor

@ogizanagi ogizanagi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this will probably lead to developers using this for use-cases for which we'll rather prone regular scalar values injection and local binding (#23718).

Copy link
Member

@chalasr chalasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 not fond of scalar injection :)

@chalasr
Copy link
Member

chalasr commented Dec 4, 2017

Should we make AbstractController use it?


public function setUp()
{
$this->containerBag = new ContainerBag(new Container($this->parameterBag = new ParameterBag(array(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on two lines would be more readable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh. I love that you are saying that, let me change this right now 😛


public function testGetAllParameters()
{
$this->assertEquals(array(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on one line is OK here to me

@nicolas-grekas
Copy link
Member Author

Should we make AbstractController use it?

could be, but not in this PR

@nicolas-grekas
Copy link
Member Author

Thank you @sroze.

@nicolas-grekas nicolas-grekas merged commit 561cd7e into symfony:master Dec 8, 2017
nicolas-grekas added a commit that referenced this pull request Dec 8, 2017
…ess parameters as-a-service (nicolas-grekas, sroze)

This PR was merged into the 4.1-dev branch.

Discussion
----------

[DI][FrameworkBundle] Add PSR-11 "ContainerBag" to access parameters as-a-service

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #17160
| License       | MIT
| Doc PR        | -

There is one thing that prevents us from not injecting the container: access to the parameter bag.
This PR fixes this limitation by providing a PSR-11 `ContainerBagInterface` + related implementation, and wiring it as a service that ppl can then also autowire using the new interface as a type hint, or `ParameterBagInterface`.

Needed to complete e.g. #24738

Commits
-------

561cd7e Add tests on the ContainerBag
0e18d3e [DI][FrameworkBundle] Add PSR-11 "ContainerBag" to access parameters as-a-service
@nicolas-grekas nicolas-grekas deleted the di-container-bag branch December 8, 2017 12:41
@nicolas-grekas
Copy link
Member Author

Should we make AbstractController use it?

@chalasr unlocked if you want to make it happen :)

@@ -4,7 +4,8 @@ CHANGELOG
4.1.0
-----

* allowed to pass an optional `LoggerInterface $logger` instance to the `Router`
* Allowed to pass an optional `LoggerInterface $logger` instance to the `Router`
* Added a new `parameter_bag` service with related autowiring aliases to acces parameters as-a-service
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

access

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will fix directly

@@ -110,6 +112,12 @@ public function load(array $configs, ContainerBuilder $container)
$loader->load('services.xml');
$loader->load('fragment_renderer.xml');

if (!interface_exists(ContainerBagInterface::class)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not just bumping the min version of the DI component instead ? This is a hard requirement already.

Copy link
Member Author

@nicolas-grekas nicolas-grekas Dec 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because I don't want to be the one breaking the 3-cross-4 compat :)

symfony-splitter pushed a commit to symfony/framework-bundle that referenced this pull request Dec 11, 2017
This PR was merged into the 4.1-dev branch.

Discussion
----------

Add ControllerTrait::getParameter()

| Q             | A
| ------------- | ---
| Branch?       | 4.1
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | symfony/symfony#25288 (comment)
| License       | MIT
| Doc PR        | n/a

Commits
-------

28397e5b2c Add ControllerTrait::getParameter()
fabpot added a commit that referenced this pull request Dec 11, 2017
This PR was merged into the 4.1-dev branch.

Discussion
----------

Add ControllerTrait::getParameter()

| Q             | A
| ------------- | ---
| Branch?       | 4.1
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #25288 (comment)
| License       | MIT
| Doc PR        | n/a

Commits
-------

28397e5 Add ControllerTrait::getParameter()
@fabpot fabpot mentioned this pull request May 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.