3
votes

First, let me say, that I find the sfFormPropel form's interface inconsistent. There is bind(), which returns nothing, but triggers validation, save() which returns the saved object, and bindAndSave(), which returns boolean, actually the return value of isValid(). Now, I have a working application, but I don't feel the code is right, and I'm quite new to symfony, so perhaps I'm missing something.

The object I need to create needs some external properties, that are not presented in the form, are external to the model, and are handled by the application (for example, the userId of the user, that created the entity, an external-generated guid, etc.).

Right now the flow is as follows:

  • get values from request and bind them to form
  • check if form is valid
  • if it's valid, add additional values and bind them to form one more time
  • save the form and return the object

The obvious answer would to add application-specific values to the values, retrieved from request, but It does not make sense to bind the application-specific values if the form is not valid, since they can be potentially expensive operations, may create database records, etc. Additionally, it should not be possible to pass those values with the post request, they should come from application only.

Now, I though that I have to let the model do these things, but since the data is external to the model, action still need to pass it to the model. The problem is, if I call $form->getObject() after bind(), it still has the old data, and not the data submitted.

What is the correct way to implement this kind of post-processing?

Second bounty is started to award the other valuable answer

2

2 Answers

2
votes

The correct way would be setting your default values on the object you are passing to the form constructor. For example if you want to set the logged in user id on an object you are creating:

$article = new Article();
$article->setUserId($this->getUser()->getId());
$form = new ArticleForm($article);
if ($request->isMethod('post')) {
  $form->bind($request->getParameter('article'));
  if ($form->isValid()) {
    $form->save();
  }
}

Likewise for existing object, you can load the record and change any properties before passing it to the form constructor.

EDIT:

If you want to modify the object after validating, you can use $form->updateObject() like Grad suggests in his response. If the generated values depend on the submitted values, you can override sfFormObject::processValues():

class UserForm {

  public function processValues($values) {
    $values['hash'] = sha1($values['id'] . $values['username']);
    return parent::processValues($values);
  }

}

In case you need something from the action, you can always pass it as an option to the form:

$form = new UserForm($user, array('foo' => $bar));

That way, you can use $this->getOption('foo') anywhere in your form code, eg. in processValues().

1
votes

It kind of depends of who has "knowledge" about the extra attributes. If they're really request specific, thus need to be processed in the controller, I go for binding, testing if valid and then update the bound object. To get the updated object with the bound (and validated) fields use the updateObject function.

$form->bind(..)
if ($form->isValid()) {

   $obj = $form->updateObject(); // Updates the values of the object with the cleaned up values. (returns object)
   $obj->foo = 'bar';

   $obj->save();
}

But since this normally is also behaviour that is form specific, I usually go for overriding the Form class. By overriding the doUpdateValues() function you can easily access submitted data, and append your own data. Of course you can also go higher in the chain, and override the save() function. To set custom data for this form, you can also 'publish' public methods, which can then be used by the controller.