Closed fabpot closed 10 years ago
This should be documented in a new cookbook article in the "Configuration" subject (we might want to split that subject into 2 subjects, but that's not related to this issue)
Following the same idea, I came up with a full implementation of a DirectoryLoader and with documented examples on how to separate everything.
See https://github.com/wemakecustom/DirectoryLoaderBundle and https://github.com/wemakecustom/symfony-kickstart/tree/master/dist for the final tree:
app
├── AppKernel.php
└── config
├── config
│ ├── common
│ │ ├── assetic.yml
│ │ ├── doctrine.yml
│ │ ├── framework.yml
│ │ ├── security.yml
│ │ ├── swiftmailer.yml
│ │ └── twig.yml
│ ├── dev
│ │ ├── assetic.yml
│ │ ├── framework.yml
│ │ ├── monolog.yml
│ │ ├── swiftmailer.yml
│ │ └── web_profiler.yml
│ ├── prod
│ │ ├── assetic.yml
│ │ ├── doctrine.yml
│ │ └── monolog.yml
│ └── test
│ ├── framework.yml
│ ├── swiftmailer.yml
│ └── web_profiler.yml
├── config.yml
├── parameters
│ ├── common
│ │ ├── core.yml
│ │ ├── i18n.yml
│ ├── dist
│ │ ├── mailer.yml
│ │ └── security.yml
│ └── local
└── routing
├── common
│ └── fos.yml
└── dev
├── common.yml
├── configurator.yml
└── profiler.yml
This also uses directories for parameters with dist/local/common folders, replacing Incenteev’s parameter builder.
If someone likes the idea, I am willing to give a hand with the documentation, improving #3885 or starting another. I would also appreciate some feedback or comments.
If people like the bundle, we can add a little tip box with a link to the bundle in that article after #3885 is merged.
I like the idea. But I don't think that this should be put in a bundle. For me, it should be a standalone library which could also be used if you used the components without the full-stack framework.
@xabbuh i think Christian is very right here, this should be a library, and try that one to be well decoupled. I think this can rock :+1:
@xabbuh @cordoval see https://github.com/symfony/symfony/issues/11045
Both of the loaders are usable as is, but you still need the bundle to register them in Symfony itself.
Do you suggest I create a project for directoryloader-di, directoryloader-routing and directory-bundle ?
Do you suggest I create a project for directoryloader-di, directoryloader-routing and directory-bundle ?
@xabbuh suggested that you should create a DirectoryLoader package with the loaders and a DirectoryLoaderBundle for their integration into Symfony. However, I don't think that is needed: It's a simple bundle and if you want the loaders, just require the bundle!
Yes, that was my idea as well. I will configure the composer.json to be permissive, without requiring symfony-framework.
I also added proper documentation: https://github.com/wemakecustom/DirectoryLoaderBundle#usage-without-symfony-framework
Well, Id rather prefer this to be separated into a library and a bundle. But I don't have too strong feelings with that. But, as @stof pointed out, your loader may be useful for Symfony itself. So, I suggest that you prepare a pull request for this on the Symfony repository.
See @fabpot 's comment saying explicitly he doesn't want it: https://github.com/symfony/symfony-standard/issues/599#issuecomment-37621837
@lavoiesl he rejected changing the default structure in symfony-standard. this does not mean he would reject including the DirectoryLoader in the component itself
Good point, I will work on this, thanks.
The docs PR for this has now been merged!
The default way to store configuration files in the Symfony standard edition was choosen for its simplicity: one file per environment. But that's just the default way.
When your configuration files grows, you might want to adopt a slightly different strategy where you create for instance one configuration file per bundle. But as it's definitely not needed by default (default configuration is quite short), I think that a cookbook about different ways to store your configuration might help people think about the best way for their project.
See symfony/symfony-standard#599 for the discussion that triggered this ticket.