It's about maintainable environments for multiple symfony projects (based 
on a globale core, e.g. a product).

I think it should be more maintainable for non-automated environments. In 
automated environments (e.g. capifony) symlinking is not a big deal as 
there's a single point of entrance for maintenance. However with manual 
environments there's currently not a single point of entrance and then 
symlinking becomes less maintainable, imho.

On the other hand symlinking could be (nicely) automated using a composer 
script handler =/

> "I wouldn't share configurations between applications, because I would 
always fear to change a setting in one app to avoid breaking the other one."
We want to manage +-100 symfony projects, these projects should share 
global configuration. Yes, changing a global config affects +- 100 
projects. This is desired for us...

I guess automated symlinks is the way to go here. However i still believe 
multiple base dirs is a nice enhancement for a more flexible system.

Op maandag 13 mei 2013 19:07:43 UTC+2 schreef Roland Franssen het volgende:
>
> Hi,
>
> I would like to start a discussion on multiple base/root dir support in 
> the HttpKernel\KernelInterface.
>
> The basic idea is that an application can have multiple "app" folders for 
> different layers of configuration, resources etc. In a nutshell; global 
> resources (e.g. app/config/parameters.yml, app/Resources/views).
>
> This should also come with a standardized bootstrap component, e.g.;
>
>> <?php
>> // web/index.php
>> $bootstrap = new 
>> Symfony\Component\Bootstrap\HttpBootstrap('global_path/:my_path/:../app'); 
>
> $bootstrap->init();
>
> $bootstrap->setup();
>> $bootstrap->run(); 
>
> $bootstrap->getKernel()->getRootDir(); // ../app 
>
> $bootstrap->getKernel()->getBasePaths(); // array('global_path/', 
>> 'my_path/', '../app');
>
>
>  However this seems to be a drastic architecture change as 
> %kernel.root_dir% is pretty much used in each bundle out there. On the 
> other hand... symfony2 is already flexible enough to handle this.
>
> I personally favor this kind of setup over symlink terror. Any thoughts on 
> this? Is it desired? Should I stop all development immediately? (I'm 
> currently working on a proof of concept for the framework bundle).
>
> Roland,
>

-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to