Annotation or Attribute to set parameters similar to bind

[Hanmac]

Description

Some Bundle has some Configuration, Might be my own Bundle or App, might be a third party one.

Now i want to use that config inside a Service. For this to work, i either need to manually set the variable inside a Extension, or i would need set them as parameter and then try to set them via bind if they are defined as parameters.

Now if the config isn't set as parameters in the Bundle Extension, it is a Problem because i might not be able to load the Config without messing with the existing Bundle.

if it is just a value using in a config what should be available in a Service, wouldn't it be better to make it configurable in the Service itself?

There might be a problem to get the right Configuration class for checking default values?

Or while writing this, should that be handled via https://github.com/sensiolabs/SensioFrameworkExtraBundle and ParamConverter?

Example

myBundle:
  email: "test@example.com"

class Service
{
    protected string $email;
    /**
     * @ParamFromConfig("myBundle.email")
     */
    public function __construct(string $email) {
        $this->email = $email;
    }
}

[stof]

The final semantic configuration of a bundle (merging the various configs provided in different files, applying default values and potentially rewriting some part of it to another place) is never stored in the container. That's the internal logic of extensions. This config could be used for anything (injecting it directly in a service definition, defining a parameter, deciding to alter the configuration of a service, deciding to load some service definitions altogether, etc...). Your proposal would not be compatible with the way semantic configuration works today, by forcing a common handling of this configuration. And it might even require some BC break (given that bundles can do what they want with their semantic configuration right now). Also, if a feature could access the final configuration, this would force all bundles to provide BC on this final configuration, which would be a huge drawback compared to today (where they only need to provide BC for the input of the processed configuration but not for the output)

[Hanmac]

@stof i already had you in mind then writing my idea/issue xD

my main problem was that in my App i wanted to use some parameters that are defined inside a bundle (in my case SonataUserBundle) and because they didn't exported the config as parameter for me to use, i couldn't access it from my App without breaking the Extension

then i noticed how annoying it was to write the config for my own services as well.

===

i did a few things for testing, and i kinda solved my main problem, loading config from another bundle with intercepting the Extension with my own one similar to a Decorator. Sadly it only works manual, so i need to registerExtension each one i where i want to grab the config.

giving that later to a Service which can be used later for the Annotations should be a smaller

Hmm another Idea: the moment when PrependExtensionInterface is called to prepend the ContainerBuilder, it probably doesn't know yet about the Annotations and what config values i might need right?

Because i could use this to get into the Extension list first, replace the other extensions with my own Decorator ones, collect their config and give that to a Service, right?

[stof]

@Hanmac are they defined in the bundle, or are they part of the configuration that you pass to those bundles ? In the second case, you can define a parameter container the value (that can then be used in your own services) and then use that parameter in the semantic config of the bundle.

[stof]

btw, the title of this issue is misleading, because bindings don't access the resolved semantic configuration of bundles either.

[Hanmac]

@Hanmac are they defined in the bundle, or are they part of the configuration that you pass to those bundles ? In the second case, you can define a parameter container the value (that can then be used in your own services) and then use that parameter in the semantic config of the bundle.

what do you mean? the Planned Annotations?

This is my current state of the Wrapper to get the Config:

class WrapConfigExtension extends Extension
{
    protected ExtensionInterface $extension;

    public function __construct(ExtensionInterface $extension) {
        $this->extension = $extension;
    }

    public function getConfiguration(array $config, ContainerBuilder $container)
    {
        return $this->extension->getConfiguration($config, $container);
    }

    public function load(array $configs, ContainerBuilder $container)
    {
        $config = $this->processConfiguration($this->getConfiguration($configs, $container), $configs);

        // example from SonataUser. At this point i would take $config and store it in my Service
        $container->setParameter('sonata_user.resetting.retry_ttl', $config["resetting"]["retry_ttl"]);
        $container->setParameter('sonata_user.resetting.token_ttl', $config["resetting"]["token_ttl"]);

        $this->extension->load($configs, $container);
    }

    public function getAlias()
    {
        return $this->extension->getAlias();
    }
}

class PrependWrapperExtension extends Extension implements PrependExtensionInterface
{
    public function prepend(ContainerBuilder $container) {
        // Iterate over all extensions, SonataUserBundle for example
        $container->registerExtension(new WrapConfigExtension($container->getExtension('sonata_user')));
    }

    public function load(array $configs, ContainerBuilder $container)
    {
        // it doesn't have its own configuration yet, maybe not needed
    }
}

about the Title of the Issue: probably, i wanted to show that while bind can access kernel/container parameters, it can't access the config, but the config could have been turned into parameters if needed.

[carsonbot]

Thank you for this issue. There has not been a lot of activity here for a while. Has this been resolved?

[carsonbot]

Could I get a reply or should I close this?

[carsonbot]

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!