because I keep forgetting this. If the configuration is: setting_name: setting_value then you can get it in the code by doing: sfConfig::get('sf_setting_name'); REMEMBER THIS: you need to attach the "sf_" to whatever the name is, but you don't have the "sf_" in the actual settings.yml file. I keep forgetting this but it's right there in the top 3 paragraphs: http://www.symfony-project.org/book/1_0/19-Mastering-Symfony-s-Configuration-Files
I thought you could just do something like this: $form = new GenericForm($generic_obj); $form->bind(); and then $form would pass an isValid() call, I was wrong. But you can do something like this: $form = new GenericForm(); $form->bind($generic_obj->toArray(BasePeer::TYPE_FIELDNAME)); and then the $form will pass: $form->isValid() I ended up not needing to do this because I refactored the code, but thought I would save this in case I do need to do it in the future
include_partial('global/PARTIAL_NAME',array('key' => 'value')); where global refers to the frontend/template directory and PARTIAL_NAME would correspond to the _PARTIAL_NAME.php template file in frontend/template (ie, full path would be frontend/template/_PARTIAL_NAME.php) and in that template file you could access $key which would contain 'value'
http://stackoverflow.com/questions/1181977/doctrine-migrations-in-symfony-dont-update-model-and-forms But once your app is in production, you obviously won't want to be ditching all the data every time you change the db schema. This is where migrations come in. * Update schema.yml * run doctrine:build-all in dev environment. * create a migration * carry out any dev/testing on a dev environment. * deploy the code to production * apply the migration to the production database.