decoupling sfServiceContainer style "import" as an sfYaml extension

[Lukas Kahwe Smith]

Hi,

I am wondering if anyone else feels like it might make sense to decouple the import syntax that Fabien created for the sfServiceContainer yaml configuration into a separate extension that could easily be used elsewhere. Essentially it would extend the sfYaml API so that it could easily be used as a drop in replacement for sfYaml with the added functionality of the import (as well as parameter) capabilities.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

[Marijn]

Hi Lukas,

I do agree with you that this functionality is very nice. Though I'm
left to wonder if that part of the code is decoupled enough to split
it out into a separate component, say sfConfigurable...
On the other hand, a real use case is hard to come up with if one is
already leveraging the sfYaml and DI component.
All in all I don't think it's worth pursuing.
Just my 2 cents, kindest regards,

Marijn

[Lukas Kahwe Smith]

On 08.01.2010, at 01:27, Marijn wrote:

> Hi Lukas,
>
> I do agree with you that this functionality is very nice. Though I'm
> left to wonder if that part of the code is decoupled enough to split
> it out into a separate component, say sfConfigurable...
> On the other hand, a real use case is hard to come up with if one is
> already leveraging the sfYaml and DI component.
> All in all I don't think it's worth pursuing.
> Just my 2 cents, kindest regards,

I have a use case:
Currently there is a lot of magic in sfDoctrinePlugin to merge schema.yml files from various sources. I think with the import support (along with parameter support and merge key support) we could give more control to the user.

[Fabien Potencier]

I think Marijn has a valid point. If you decouple too much, then it
suddenly become a nightmare to use the components because of the many
dependencies.

For your use case, this is probably something that will be done with the
DI new extension mechanism in Symfony 2, which means that you will have
import support out of the box.

That's one major improvement I want in Symfony 2: less concepts to
grasp. So, we will use the DI container as much as possible.

For those who have not read the new extension code, here is an example
of its usage in an XML and YAML file:

<doctrine:dbal>
<dbname>sfweb</dbname>
<username>root</username>
<password></password>
</doctrine:dbal>

<swiftmailer:mailer transport="gmail">
<username>fabien.potencier</username>
<password>xxxxx</password>
</swiftmailer:mailer>

swiftmailer.mailer:
transport: gmail
username: fabien.potencier
password: xxxxx

Extensions are a way to describe semantically your configuration, and
the extension convert this to regular parameters and services.

That way, the DI container can be used to replace settings.yml,
factories.yml, but also databases.yml, routing.yml, schema.yml, and all
other configuration files.

Fabien