propelorm/sfPropelORMPlugin — Issue #110: properties of propel.ini are not resolved in sfPropel*Tasks
Author: ck-1
Created: 2012-02-10 08:28:31+00:00
State: open

If "variables" are used in the propel.ini, they are not resolved by the symfony tasks but by the phing tasks.

E. g.:

propel.schema.dir = ${propel.output.dir}/config
propel.conf.dir = ${propel.output.dir}/config
propel.phpconf.dir = ${propel.output.dir}/config
propel.sql.dir = ${propel.output.dir}/data/sql

propel.platform.class = plugins.ownPropelExtraPlugin.lib.platform.own${propel.database}Platform

This is because in the sfPropelBaseTask in the getGeneratorConfig method the propel.ini is loaded by using parse_ini_file. The phing Properties class uses an own parser and the phing PropertyTask has a resolveAllProperties method for this purpose.

Because the resolveAllProperties methode neither is public nor static, I had to copy this method and the method parsePropertyString to the sfPropelBaseTask as a quick fix and replaced the parse_ini_file in the getGeneratorConfig method by this code:

require_once dirname(__FILE__).'/../vendor/phing/Phing.php';
require_once dirname(__FILE__).'/../vendor/phing/system/util/Properties.php';
$props = new Properties();
try { // try to load file
Phing::startup();
$file = new PhingFile($iniFile);
$props->load($file);
$this->resolveAllProperties($props);
$params = $props->getProperties();

A better solution could be to extract the phing ini file parser as an independent class which could used by the phing PropertyTask and the sfPropel*Tasks. Or does a component doing this already exist somewhere?