Symfony Per Developer Configuration under Version Control
The Problem
Are you a Symfony developer who work with several other developers, and you share your progress with them using a Version Control System (VCS)? Subversion, GIT, Mercurial, you name it. In a team based development environment, it's not uncommon that each of the developer needs to have some sort of personalized configurations. For example, in ProjectConfiguration.class.php, where you define your Symfony library include path: require_once '/home/user/projects/lib/symfony-1.4.8/lib/autoload/sfCoreAutoload.class.php';. In the single developer scheme, this works perfectly fine. However, in team development scheme under version control, this fails. That's because if you commit this file into VCS, it will alter the include path of the rest of the team.
Obvious solution are:
1) Force every person in the team to use the same include path.
2) Exclude this file from committing into VCS.
Solution (1) will probably generate a lot of rants from your teammates. What if you are using Linux and your teammate is on Windows?
Solution (2) will work, but how do you keep the changes synchronized among your teammates? You might say I don't change this file much anyway, but you do change it right? In a large project, I've change this file MANY times during the lifetime of the project. It's really annoying if I have to inform my team every time I make change to this file. This one file mentioned here is just an example, there are some other files need to be personalized too, for instance, app.yml, database.yml.
The Solution
So I propose a third solution here. Not a perfect one, but it's good enough. Here's how:- Create an empty PHP file under PROJECT_ROOT/config/personalizedConfig.php. You can name this file whatever you want, I named it personalizedConfig.php. Remember to EXCLUDE this file from committing into version control system.
- Move the line that includes the Symfony library from PROJECT_ROOT/config/ProjectConfiguration.class.php to this file.
- Put the settings you want to personalized here. I created a helper class to store and retrieve setting.
- Include the file you've just created to ProjectConfiguration.class.php.
#ProjectConfiguration.class.php
<?php
require_once dirname(__FILE__) . '/personalizedConfig.php';
sfCoreAutoload::register();
class ProjectConfiguration extends sfProjectConfiguration {
//omitted...
}
#personalizedConfig.php
<?php
require_once '/home/user/projects/lib/symfony-1.4.8/lib/autoload/sfCoreAutoload.class.php';
class myPersonalizedConfig {
private static $buff = array();
private function __construct() {
}
public static function set($key, $value) {
self::$buff[$key] = $value;
}
public static function get($key, $default = null) {
if (!isset(self::$buff[$key])) {
return $default;
}
return self::$buff[$key];
}
}
myPersonalizedConfig::set('db_host', 'localhost');
myPersonalizedConfig::set('db_name', 'mydb');
myPersonalizedConfig::set('db_username', 'username');
myPersonalizedConfig::set('db_password', 'password');
myPersonalizedConfig::set('app_site_url', 'http://www.example.com');
Now you and your teammates are free to put the Symfony library to the desired location.
Another beauty of this is that you can avoid committing sensitive information into the version control system. For example, in your database.yml, you defined production environment database information. In this case you certainly don't want it to be committed into the version control system. Symfony's yml configuration file is so well designed that you can place PHP code directly into it.
#database.yml
prod:
doctrine:
class: sfDoctrineDatabase
param:
dsn: 'mysql:host=<?php echo myPersonalizedConfig::get('db_host') ?>;dbname=<?php echo myPersonalizedConfig::get('db_name') ?>'
username: "<?php echo myPersonalizedConfig::get('db_username') ?>"
password: "<?php echo myPersonalizedConfig::get('db_password') ?>"
You can do likewise to app.yml. As always, you are welcome to provide your feedback below.
Leave a Comment
If you would like to make a comment, please fill out the form below.
To my beloved readers:
Please note that you may freely post comments here, but I will most likely not be able to reply to most them due to my current availability.
Loading ...
The only file that usually differs is the databases.yml file, which should be excluded from svn anyways for security reasons, and instead you just include a databases.yml.dist file that doesn't contain the credentials, and each developer copies and customizes that.
- Besides databases.yml, app.yml fits in this category too. For example, when defining the website URL. Even factories.yml can be fit into this category. For example, when setting up "single_address" delivery strategy, this method will allow developers to set their preferred email address under the same environment. So instead of exclude these files from SVN, by using this method, you can commit them and yet allow other developers to change the setting to values their preferred.
[url=http://2.sapato-shopping.ru/karlo-pazolini-internet-magazin-cat/parfois-sumki-internet-magazin.php]parfois сумки интернет магазин[/url]
[url=http://2.sapato-shopping.ru/obuv-21-veka-cat/internet-magazin-sportivnoy-obuvi-adidas.php]интернет магазин спортивной обуви adidas[/url]
[url=http://2.sapato-shopping.ru/baskoni-cat/internet-magazin-obuvi-skeytera.php]интернет магазин обуви скейтера[/url]
[url=http://2.sapato-shopping.ru/solomon-obuv-cat/obuv-carlo-pazolini-internet-magazin.php]обувь carlo pazolini интернет магазин[/url]
[url=http://2.sapato-shopping.ru/karlo-pazolini-internetmagazin-cat/juicy-couture-obuv-internet-magazin.php]juicy couture обувь интернет магазин[/url]