How to force symfony colors on windows with PuttyCyg?
Those of you who’re developing with symfony under windows will have noticed that, when running tasks in the command prompt, no colors are used. This is because the windows command prompt isn’t compatible with the color notation.
Most of you also have cygwin installed (shame on you if you didn’t :p). But even if you run the tasks through “PuttyCyg”, which is fully compatible with the color notation, you will not benefit from the colors.
Why?
Interview: Stefan Koopmanschap
A few weeks ago I thought it might be cool to get some interesting guys, which are occupied with projects in PHP, interviewed. And guess what, we got on contact with Mr. Stefan Koopmanschap and he was kind enough to answer all our questions.
Stefan Koopmanschap ('left') is a PHP developer, consultant and trainer with an eye for best practices. He works at Unet as (symfony) developer and development team leader. He is a community person and is active in the european PHP community as secretary of the phpBenelux Usergroup as well as in the Symfony community by advocating symfony and as the Community Manager.
Stefan has a wide history in Open Source, having been Support Team Leader for phpBB, documentation translator for Zend Framework and community manager, plugin developer and maintainer plus various other things for symfony.
Stefan is also a best practices advocate. He prefers easy and useful explanations of best practices over the academic and theoretical stuff found in most literature.
Hope you enjoy this interview!
Hello Stefan, first of all, thx for taking the time to answer all our questions.
Can you tell us what projects you are currently working on?
At work I am involved in a big project to build an application that will handle all the administration, provisioning and handling of user accounts etc. for the whole VOiP and connectivity of the services we offer. Aside from that, my main projects are being the Community Manager for symfony and also preparing some new talks for the upcoming conferences.
Basic forms with Symfony
Our goal is to create a little crud that contains 4 fields
id (auto increment integer)
name (varchar 50)
value (double)
type (0 or 1)
What I will explain is how to change your fields in the form after creation with generation of a module. So we start with a clean module that contains 1 action class and 3 templates (new, edit and index) and 1 partial (form) that is included on the new and edit template.
We created this module not by hand but with the very easy command: symfony propel:generate-module.
Symfony Form: unsetAllFieldsExcept()
When creating forms in symfony which extends from a Base (ORM) class, you sometimes do not need all fields that Propel/Doctrine generates for you. If you want to remove them you have several ways to do so.
1. Unset the fiels you don't need.
public function configure() {
unset($this['field1'], $this['field2'], ... );
}
Simple way to remove the fields you don't want, but if you change something in your database, which has an impact on that form (new column, foreignkey, etc ), it will be added in the (generated) super class. And if you don't update the unset function with that extra field, it will be expected in the form. Unless you have unit tests for all your forms this could brake it without knowing it.
2. Override the setup function.
/**
* @override
*/
public function setup()
{
parent::setup();
$this->setWidgets(...);
$this->setValidators(...);
}
Another way is to override the setup function and do your own widgets and validators initialization. This is a good way to only intialize the fields you really need, but you'll have to do what your ORM generated for you.
3. Use a function which unsets all fields except the one you need (like the enableAllPluginsExcept function).
$this->unsetAllFieldsExcept(array(
'field1',
'field2',
'field3',
...));
This would be usefull, because it will remove all fields you do not want to use, and even if new fields are added it will not use them. The drawback is that if you have 20 fields and only need to unset one of them, you'll have more type work 
.
Since it does not exist in symfony, I quickly created our own function. This function should be added in the class BaseFormPropel.class:
abstract class BaseFormPropel extends sfFormPropel
{
public function setup() {
}
protected function unsetAllFieldsExcept($fields = array()) {
$unsetFields = array_diff(array_keys($this->getWidgetSchema()->getFields()), $fields);
foreach($unsetFields as $value) {
unset($this[$value]);
}
}
}
Which one to use ?
None of them are better. But if you need to reset a majority of the fields the ORM has generated then I would go for the method 2. If you only need to unset the fields you do not want to use then I would use the function unsetAllFieldsExcept().
Which method do/would you use ?
sfWidgetFormInputCheckbox unchecked bug
Ever tried to create a Symfony form with a check box input field, which by default should be unchecked ? No ? Well read on because it's not that easy 
.
This would be the code to print a check box input field in a Symfony form:
class CheckboxForm extends BaseCheckboxForm {
public function configure() {
$this->widgetSchema['field'] = new sfWidgetFormInputCheckbox();
}
}
When you use the form to create something then by default the check box should be unchecked. And when you use this form for editing, then the check box should be checked if the object you try to edit has already been checked in the past.
If you try this code, you'll see that the check box will always be checked. Even if you display this form to create a new object. Strange no ?
Interesting People – part 1: Fabien Potencier
Nothing better to get inspiration from then a nice cup of Nespresso in the evening. We are working with Symfony for a few months (years) now and I was wondering earlier this day: Who are the guys that are able to produce such a nice piece of software? You got to admit it that the framework these guys created is a masterpiece, must be a shitload of work and it is still growing on a daily basis.
Off course there is more then one person creating this software, but 1 man in particular is leading this project: Fabien Potencier.
Symfony Forms Framework: Merge 2 forms
Recently I had to create a form to create/update users in our system. Some time ago we decided to save are users in 2 tables. The first table would contain all login information and the second his personal information. This is a simple example of the DB design:
User db design
I would not recommend doing this for so little fields. But in our system we have a lot more fields, and it helps us to optimize our queries.
Wouldn't it be better if we could merge the 2 forms? The answer is yes. And it's pretty easy to do so in Symfony ... too bad that it’s not documented on the Symfony website.
Symfony Forms Framework: Change validators at runtime.
Let’s say you have to make a user form with password fields. When you create the user you want the password fields to be required, but on an update the password fields should be optional because you don’t want the user the fill in his password on each update.
This is tricky because in the symfony forms Framework you have to predefine your validators. Your form would look like this:
class UserForm extends BaseUserForm {
public function configure() {
// Widgets
$this->widgetSchema['password'] = new sfWidgetFormInputPassword();
$this->widgetSchema['password_again'] = new sfWidgetFormInputPassword();
// Validators
$this->validatorSchema['password']->setOption('required', false);
$this->validatorSchema['password_again'] = clone $this->validatorSchema['password'];
$this->widgetSchema->moveField('password_again', 'after', 'password');
$this->mergePostValidator(new sfValidatorSchemaCompare('password', sfValidatorSchemaCompare::EQUAL, 'password_again', array(), array('invalid' => 'The two passwords must be the same.')));
}
}
In this signature of the form I defined the password and password_again field as optional, which is correct for an update of the user, but incorrect for the creation of the user. How the hell can I change the validator of the password field when I create a user ?
Well thanks to the good and well designed framework of symfony it is very simple .
class UserForm extends BaseUserForm {
public function configure() {
// Widgets
$this->widgetSchema['password'] = new sfWidgetFormInputPassword();
$this->widgetSchema['password_again'] = new sfWidgetFormInputPassword();
// Validators
$this->validatorSchema['password']->setOption('required', false);
$this->validatorSchema['password_again'] = clone $this->validatorSchema['password'];
$this->widgetSchema->moveField('password_again', 'after', 'password');
$this->mergePostValidator(new sfValidatorSchemaCompare('password', sfValidatorSchemaCompare::EQUAL, 'password_again', array(), array('invalid' => 'The two passwords must be the same.')));
}
public function bind(array $taintedValues = null, array $taintedFiles = null) {
if ( $this->object->isNew() ) {
$this->validatorSchema['password']->setOption('required', true);
}
parent::bind($taintedValues, $taintedFiles);
}
}
What I did is override the function bind and before calling the bind method of the parent, I checked if the user object is new (means that we create a user) and if this is the case set the required option of the password field to true.
symfony 1.3
symfony announced a new release in November 2009 and will be going from 1.2 to 1.3.
It’s wonderful that these guys are thinking ahead and keeping us up to date. Why is this important, you ask? Well would you invest in software that isn’t trying to evolve to a better version, to a more reliable version? I don’t think so. Like in our case: We started developing software in October 2007 and needed a part of the project to be PHP-based. The choice of framework wasn’t that easy but the great documentation and the future developments convinced us to use symphony. And we didn’t regret our choice for one minute. Fabien Potencier and his crew keep their promises to the developers and users.
I can quote him as they give good reasons why they should keep us up to date:
- the users will have time to learn all the great symfony 1.2 features compared to symfony 1.0
- the core team will have plenty of time to make symfony 1.3 rock solid
- the documentation team will have time to write even more tutorials and blog posts
- the plugin developers will have plenty of time to upgrade their plugins to 1.2 with confidence that their work will still be relevant for 1.3.
Great work guys, keep us up to date, in the mean time we’ll do just fine with the 1.2 version.
Jobeet
Symfony, ah we just love the framework... A year ago we started using this php framework and we wrote a post on it a few months ago (read). In 2005 the creators of Symfony wrote a step by step tutorial on how to build a website with their framework. For me and my colleagues, this was the ideal guide to learn it and get to know the best way to use it.
Now, 3 years later, they are publishing a new 24 hour tutorial called Jobeet. If you want to know more and follow this tutorial, click on the link in the sidebar or here.