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 ?

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 ?

The problem is due to a bug in the Symfony sfWidgetFormInputCheckbox class. Even worse, this bug has been reported the first time 10 months ago (trac #3917) and 1 month later (trac #3996) and it’s still not fixed ! (grrrrr)

Until Symfony bug fixes this issue, there are 2 work a rounds you can use.

1. Edit the sfWidgetFormInputCheckbox class and patch it:

actual

class sfWidgetFormInputCheckbox extends sfWidgetFormInput
{
 ...
 public function render($name, $value = null, $attributes = array(), $errors = array())
 {
 if (!is_null($value) && $value !== false)
 {
 $attributes['checked'] = 'checked';
 }
 ...
 }
}

patched

class sfWidgetFormInputCheckbox extends sfWidgetFormInput
{
 ...
 public function render($name, $value = null, $attributes = array(), $errors = array())
 {
 if (!is_null($value) && $value !== false && $value != 0)
 {
 $attributes['checked'] = 'checked';
 }
 ...
 }
}

I would not recommend this, because if like us, you have more than one Symfony environment, there is a chance that you could forget to patch it. And worse if Symfony releases a new version without the bug fix you’ll have to remember to re patch the file.

2. Extend the sfWidgetFormInputCheckbox class and override the render method:

Edit: Put this class in the lib folder and call it myOwnWidgetFormInputCheckbox.class.php. After that run symfony cc.

/**
 * FIXME: This class can be removed if the sfWidgetFormInputCheckbox bug
 * has been resolved in symfony.
 */
class myOwnWidgetFormInputCheckbox extends sfWidgetFormInputCheckbox
{
 /**
 * Override render method due to symfony bug (http://trac.symfony-project.org/ticket/3917)
 */
 public function render($name, $value = null, $attributes = array(), $errors = array())
 {
 if (!is_null($value) && $value !== false && $value != 0)
 {
 $attributes['checked'] = 'checked';
 } 

 if (!isset($attributes['value']) && !is_null($this->getOption('value_attribute_value'))) {
 $attributes['value'] = $this->getOption('value_attribute_value');
 }

 return parent::render($name, null, $attributes, $errors);
 }
}

Your form class should then be changed to:

class CheckboxForm extends BaseCheckboxForm {
 public function configure() {
 $this->widgetSchema['field'] = new myOwnWidgetFormInputCheckbox();
 }
}

This was very easy to solve, but we lost a lot of time in finding the reason why this stupido check box was always checked. And why the hell is this bug still not solved in Symfony ?

In the mean time patch your symfony or create your own checkbox widget .

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.

When you generate the forms with Symfony, you’ll get a UserForm and a UserInfoForm.

/**
* User form.
*
* @package    form
*/
class UserForm extends BaseUserForm {

public function configure() {

}

}

/**
* UserInfo form.
*
* @package    form
*/
class UserInfoForm extends BaseUserInfoForm {

public function configure() {

}

}

The idea is to display one form to insert/update those 2 tables. If you are familiar to creating forms with Symfony you know that you could achieve it by instantiating the 2 forms in an action and send them to the templates:

/**
* Action Class
*/
class userActions extends sfActions
{
public function executeCreate($request) {
$this->userForm = new UserForm();
$this->userInfoForm = new UserInfoForm();
$this->setTemplate('edit');
}

public function executeEdit($request) {
$this->userForm = new UserForm(UserPeer::retrieveByPK($request->getParameter('id')));
$this->userInfoForm = new UserInfoForm(UserInfoPeer::retrieveByPK($request->getParameter('id')));
}

public function executeUpdate($request) {
$this->userForm = new UserForm(UserPeer::retrieveByPK($request->getParameter('id')));
$this->userInfoForm = new UserInfoForm(UserInfoPeer::retrieveByPK($request->getParameter('id')));

$this->userForm->bind($request->getParameter($this->userForm->getName()));
$this->userInfoForm->bind($request->getParameter($this->userInfoForm->getName()));

// etc ...
}
}

// Template code editSuccess.php
<?php $user = $userForm->getObject(); ?>

<form action="<?php echo url_for('user/update'.(!$user->isNew() ? '?id='.$user->getId() : '')) ?>" method="post">
<table>
<tfoot>
<tr>
<td colspan="2">
<input type="submit" value="Save" />
</td>
</tr>
</tfoot>
<tbody>
<?php echo $userForm ?>
<?php echo $userInfoForm ?>
</tbody>
</table>
</form>

This is really annoying to work this way. You always have to instance 2 forms in the action and the templates. 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.

Here is how you do it:

1. UserForm.class.php

/**
* User form.
*
* @package    form
*/
class UserForm extends BaseUserForm {

public function configure() {
$this->mergeForm(new UserInfoForm(UserInfoPeer::retrieveByPK($this->getObject()->getId())));
}

/**
* Override the save method to save the merged user info form.
*/
public function save($con = null) {
parent::save();

$this->updateUserInfo();

return $this->object;
}

/**
* Updates the user info merged form.
*/
protected function updateUserInfo() {
// update user info
if (!is_null($userInfo = $this->getUserInfo())) {

$values = $this->getValues();
if ( $userInfo->isNew() ) {
$values['user_id'] = $this->object->getId();
}

$userInfo->fromArray($values, BasePeer::TYPE_FIELDNAME);

$userInfo->save();
}
}

/**
* Returns the user info object. If it does
* not exist return a new instance.
*
* @return UserInfo
*/
protected function getUserInfo() {

if (!$this->object->getUserInfo()) {
return new UserInfo();
}

return $this->object->getUserInfo();
}
}

2. actions.class.php

public function executeCreate($request) {
$this->form = new UserForm();
$this->setTemplate('edit');
}

public function executeEdit($request) {
$this->form = new UserForm(UserPeer::retrieveByPK($request->getParameter('id')));
}

public function executeUpdate($request) {

$this->forward404Unless($request->isMethod('post'));

$this->form = new UserForm(UserPeer::retrieveByPK($request->getParameter('id')));

$this->form->bind($request->getParameter($this->form->getName()));
if ($this->form->isValid()) {
$user = $this->form->save();
$this->redirect('user/edit?id='.$user->getId());
}

$this->setTemplate('edit');
}

3. editSuccess.php

<?php $user = $userForm->getObject(); ?>

<form action="<?php echo url_for('user/update'.(!$user->isNew() ? '?id='.$user->getId() : '')) ?>" method="post">
<table>
<tfoot>
<tr>
<td colspan="2">
<input type="submit" value="Save" />
</td>
</tr>
</tfoot>
<tbody>
<?php echo $userForm ?>
</tbody>
</table>
</form>

As you can see, it’s the UserForm that will handle all the business of the UserInfoForm. This is great because the code in the action and template will be much more lightened and if needed it can easily be reused somewhere else.

This was a simple example on how to merge 2 forms, but since it’s not documented on the symfony website, it took me some time to fully understand on how to make it work. Now you can do much more advanced operations.

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.

A lot of people create easy forms but don’t think it trough before designing the page. I listed 5 useful attributes/elements a lot of people intend to forget or simply don’t know why they are using it.

Use get or post to send a form

Get will append the form data to the URL that is set in the action attribute of the form and is used when the form is idempotent. For example on search forms.
Post will not append it to the URL but sent it in the body of the form. It should be used when we are modifying a database or doing a subscription.

What is enctype?

This attribute is used to submit the form to the server; it is only needed when using post. Whenever you use a file field in your form you should set the enctype value to multipart/form-data, otherwise it uses the default value application/x-www-form-urlencoded.

Use tabindex

This creates an order when going from one field to the next using your tab button. When creating complex forms, this might come in quite handy. It creates the opportunity for the developer to indicate the order the form needs to be completed. Every field in the form gets a ‘tabindex’ value starting from 0 with a maximum of 32767.

Connect a label to a field

It’s always handy to have a label for each input field, so you can click on the label and the cursor automatically gets positioned in the input field. The only thing to do is put a ‘for’ attribute in the label and give it the id of the corresponding field as value. Easy and Handy for users

Fieldset and legend

This allows you to thematically group your form elements. The ‘legend’ element gives you the opportunity to create a title on each fieldset and has to be put in between the fieldset tags. Use css styling to create a nice design for the fieldset.

Greetings K.

AjaxForm or ajaxSubmit

This plug-in provides numerous options you can call to manage your form before and after submission and all this in AJAX. More info on http://malsup.com/jquery/form/

Live Query

When an element is loaded into a page, you will not be able to use the events on this element. But when the Live Query is used, this magically appears to work… This is because the Live Query binds events of elements together every few milliseconds and does a DOM (Document Object Model) update. A really cool plug-in that creates the possibility for web developers to execute events without reloading the page every time an element is clicked. The only disadvantage of live query is the fact that it appears to slow down the execution time a bit, but when you don’t have to reload your page each time, I guess it’s worth the usage. More info on http://brandonaaron.net/docs/livequery/

JSON (JavaScript Object Notation)

In our case we are using JSON as response-type from an AJAX request. This is a sort of XML but a lot easier to read, especially when you work with a lot of data. For more information on JSON visit http://json.org/ or http://borkweb.com/story/the-case-for-json-what-is-it-and-why-use-it