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

Skip to content

[DependencyInjection] Add custom container configurators #25650

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

Closed

Conversation

unkind
Copy link
Contributor

@unkind unkind commented Jan 1, 2018

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

@unkind unkind force-pushed the feature-custom-container-configurator branch 3 times, most recently from 398cfdd to 8d9d172 Compare January 2, 2018 00:49
@unkind unkind force-pushed the feature-custom-container-configurator branch from 8d9d172 to 00e830f Compare January 2, 2018 00:52
@nicolas-grekas nicolas-grekas added this to the 4.1 milestone Jan 2, 2018
@unkind
Copy link
Contributor Author

unkind commented Feb 21, 2018

Any chance to merge it in 4.1?

It's a challenge to make it without changes in the core so far: ContainerConfigurator requires PhpFileLoader as dependency (probably, FileLoader is enough?). /cc @nicolas-grekas

@ro0NL
Copy link
Contributor

ro0NL commented Feb 22, 2018

What about something like

$c->extension('my_ext', ['primitive' => 'config']);

// vs.

/** @var MyExtConfigurator $myExt */
$myExt = $c->extension('my_ext');
$myExt
   ->fluent('config');

Thus support both flavors, as well as multiple extension per-config.

With a corresponding ConfiguratorAwareConfigurationInterface or so?

@andersonamuller
Copy link
Contributor

Or:

$myExt = $c->extension('my_ext')->configure(function (MyExtConfigurator $myExt) {
	return $myExt->foo('bar');
});

@ro0NL
Copy link
Contributor

ro0NL commented Feb 22, 2018

Or:

$c->extension(function(MyExtConfigurator $e) {
   $e->fluent('config');
});

Where's my cookie? :)

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Mar 23, 2018

I'm not convinced this is the approach we need in core.

The idea I proposed in #25630 doesn't require any code at all, thus not any new concept/methods/api:

return function (ContainerConfigurator $c) {
    $myBundle = new MyBundleConfigurator($c);

    $myBundle->setWhatever();
}

To me, configuration is the correct place to do "new".

Note that I'd also really like to be able to autocomplete bundle config using fluent configurator.
Unfortunately, this is currently left as "an exercise" to bundle authors (and the exercise is not trivial).
Would be awesome to be able to somehow autogenerate it from config definition!

@nicolas-grekas nicolas-grekas modified the milestones: 4.1, next Apr 20, 2018
@nicolas-grekas
Copy link
Member

@unkind can you check #27065? I think it could fix your issue in a nice way. WDYT? I'm closing this PR as explained above. Thanks for proposing.

@unkind
Copy link
Contributor Author

unkind commented Oct 21, 2018

@unkind can you check #27065? I think it could fix your issue in a nice way.

Hmm, what's the difference? Closure or anonymous class?

The issue is a bit deeper than it may look.
Maintainers of bundles don't know and don't want to support this type of configuration.
I still don't see it for Monolog bundle, for example (like in my proposal here: #25630).
I'm pretty sure that simple "official" support at extension level could be nice push for them, because it's "official" way.
Just think about it like ... sales manager, not programmer. :)

Also, PhpFileLoader is still cannot be extended in user-land with custom injected file.

YAML/XML are cool when you need to generate them, e.g. you have some kind of "hexagons" (in terms of hexagonal architecture), they have different namespaces, you have to register it for auto wiring, etc., so config generation here is perfect solution.

But when you deal with manual changes, I still don't see better solution than plain PHP.

@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 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.

5 participants