First, the code igniter framework is a lot less code than symfony (and much easier to install).   The result it seems, is a faster snappier website.  Additionally, digging through the code igniter framework to see what’s going on, is 10x easier than going through the symfony framework base code.  I know some ppl will argue that the caching on symfony should make it just as fast, but honestly, I dont see it.  I’ve tried many different caching strategies that they outline online and in the forums, but code igniter’s simple view template strategy seems much faster.

Code igniter currently doesn’t come with a default ORM.  Because of the lack of an ORM, pulling data from the database is much faster compared to Doctrine’s access.  I was running a 4million record database that linked to a 2 million record database.  Doctrine pretty much puked on this.  I haven’t seen an issue yet with this with the Code igniter database class.  I think the many abstraction layers that Doctrine has results in unnecessary classes which leads to slower results access and increases the chances of memory leaks.  Say what you may, but these are the results that i’ve found for my website.

http://www.symfony-project.org/blog/2008/10/14/new-in-symfony-1-2-make-your-choice

One thing to note:  if you need a multiple checkboxes for one value (in php it’s handled like so: varname[]), you would use the sfWidgetFormChoice with the multiple=>true and expanded=>true.

Also, if it’s an array of values, use sfValidatorChoiceMany instead of sfValidatorChoice.

-d

What this means is that now when you are trying to use the array in a view, you need to call the getRaw function that sfOutputEscaperArrayDecorator has.  SO:

in your action:

$my_array = array(1,2,3,4);

in your view print_r($my_array) will throw in error.  what you need to do instead is:

print_r($my_array->getRawValue());

I haven’t tested the rest of the objects out, but im assuming you can get the actual object by calling getRaw() on the variable name.

-d

adding multiple postvalidators:

$this->validatorSchema->setPostValidator(new sfValidatorSchemaCompare(‘password’, sfValidatorSchemaCompare::EQUAL, ‘password_again’, array(), array(‘invalid’=> ‘Password and Password Again do not match.’)));
$this->mergePostValidator(new sfValidatorSchemaCompare(‘email’, sfValidatorSchemaCompare::EQUAL, ‘email_again’, array(), array(‘invalid’=> ‘Email and Email Again do not match.’)));

If you use sfValidatorAnd in your forms, the individual error messages no longer matter.  The error message of the sfValidatorAnd is used instead.

‘email’             => new sfValidatorAnd(array(
new sfValidatorString(array(‘max_length’ => 60)),
new sfValidatorEmail()), array(), array(‘required’=>’Email is required.’, ‘invalid’=>’Email is invalid.’)),

Finally, to get to all the errors in the form:

$form->getErrorSchema()->getErrors()

to get to all the global errors in the form:

$form->getGlobalErrors()

Some problems occurred when executing the task:
build-propel.xml:479:1: Duplicate table found: propel.
build-propel.xml:465:121: Execution of the target buildfile failed. Aborting.
If the exception message is not clear enough, read the output of the task for more information

So when you’re reverse engineering a database schema, you’ll likely get this error if you have plugins installed and you try to do a propel:build-model. For instance, if you have a an existing database and you’re doing a ./symfony propel:build-schema, it will go in and create a new schema.yml for you.  But, you have tables in there that the plugins will take care of, so there will be a conflict.  To fix this, you should go into the generated schema.yml and clear out the additional tables.  Then run the build-model again.