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

[DependencyInjection] Compiler pass before merge #23491

Closed
Padam87 opened this Issue Jul 12, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@Padam87
Contributor

Padam87 commented Jul 12, 2017

Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? no
Symfony version >=3.4

Hi,

We have recently started to develop a new system, and one of the requirements is to be able to change some parameters from the admin section. (These parameters would normally belong to parameters.yml, or config.yml:parameters)

Unfortunately some of these parameters are needed compile time.
The OpenSkyRuntimeConfigBundle is very good for some use cases, but it uses expressions, so it can only be used for service arguments directly. This would be fine if you write everything on your own, but that is almost never the case.

For example, in our case, the following extensions depend on the locale parameter: framework, stof_doctrine_extensions, jms_translation, jms_i18n_routing.

I will solve this by creating a parameters.php file, which reads the config, but I think this would be a nice use case for a compiler pass that runs before the MergeExtensionConfigurationPass.

PassConfig::TYPE_BEFORE_MERGE

Any chance of accepting a PR like this?

(It would be even better if somehow we could pass expressions/callbacks as parameters, but thats a tall order :))

@Padam87 Padam87 changed the title from Compiler pass before merge to [DependencyInjection] Compiler pass before merge Jul 12, 2017

@javiereguiluz

This comment has been minimized.

Show comment
Hide comment
@javiereguiluz

javiereguiluz Jul 16, 2017

Member

@Padam87 in one project I use the parameters.php file that you mention for some highly dynamic params that can't be defined as env vars or in any other way.

Adding a new compiler pass type is a very serious change, so I'd say that it's better to keep using the parameters.php file (unless you find a use case that you can't solve with that). Thanks!

Member

javiereguiluz commented Jul 16, 2017

@Padam87 in one project I use the parameters.php file that you mention for some highly dynamic params that can't be defined as env vars or in any other way.

Adding a new compiler pass type is a very serious change, so I'd say that it's better to keep using the parameters.php file (unless you find a use case that you can't solve with that). Thanks!

@Padam87

This comment has been minimized.

Show comment
Hide comment
@Padam87

Padam87 Jul 16, 2017

Contributor

Hi @javiereguiluz,

We wanted this as a private, but reusable bundle.

I've ended up creating a parameters.php file and loading it via prepend in the bundle's extension.

    /**
     * {@inheritdoc}
     */
    public function prepend(ContainerBuilder $container)
    {
        $loader = new Loader\PhpFileLoader($container, new FileLocator(__DIR__.'/../Resources/config'));
        $loader->load('parameters.php');
    }

It works well, so if the new pass is too much, this can be closed.

Contributor

Padam87 commented Jul 16, 2017

Hi @javiereguiluz,

We wanted this as a private, but reusable bundle.

I've ended up creating a parameters.php file and loading it via prepend in the bundle's extension.

    /**
     * {@inheritdoc}
     */
    public function prepend(ContainerBuilder $container)
    {
        $loader = new Loader\PhpFileLoader($container, new FileLocator(__DIR__.'/../Resources/config'));
        $loader->load('parameters.php');
    }

It works well, so if the new pass is too much, this can be closed.

@Padam87 Padam87 closed this Jul 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment