-
- Item
- 28 October 2009
- Jaymon
get configuration settings #symfony #learned
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
-
- Item
- 17 October 2009
- Jaymon
bind an object to a form #symfony #learned
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
-
- Item
- 5 October 2009
- Jaymon
partial templates #symfony #learned
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'
-
- Item
- 25 September 2009
- Jaymon
table of contents that you need to have on hand #learned #symfony
definitive guide to symfony: http://www.symfony-project.org/book/1_2/ symfony forms in action: http://www.symfony-project.org/forms/1_2/en/
-
- Item
- 25 September 2009
- Jaymon
Doctrine migrations in symfony don't update model and forms - Stack Overflow #learned #symfony
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.