Embedding Child forms with sfFormPropel - A Practical Example

As it turns out, when it comes to creating rich Symfony forms using embedForm, the solution depends greatly on the answer to this question: Does your main form extend sfFormPropel or sfForm? In two previous articles, I created a simple todo list and extended it to make it more useful. In those articles, my main form extended sfForm. Today, I'm going to cover a similar (and probably more useful) example where my main form extends sfFormPropel.

The Goal

Our goal is to create a simple interface to manage Author information and their Publications. As you may have guessed, each Author can have many Publications. These will be our Propel objects. Similar to my advanced todo list, we'll be adding AJAX to make the interface more user-friendly.

Play around with our Author-Publication Form

The setup

Simple. Our schema is a parent "Author" model and a child "Publication" model. I won't display the actions and template code here, because they're almost identical to my previous article. The point I want to make here is how embedding forms into sfFormPropel differs from sfForm. You can download the full source to this project at the bottom of the article.

//schema.yml
propel:
  author:
    _attributes:   { phpName: Author }
    id:
    first_name:    varchar(255)
    last_name:     varchar(255)
  publication:
    _attributes:   { phpName: Publication }
    id:
    author_id:     { type: integer, foreignTable: author, foreignReference: id, onDelete: cascade, onUpdate: cascade, required: true }
    title:         varchar(255)
    year:          integer

The Meat: The Forms

Our main form (the one we actually render in the template and initialize in the actions) is called myAuthorForm and it extends the propel-generated AuthorForm. This form is configured below. Notice that there is no real difference between the configuration here and the one used in my previous todo list article.

class myAuthorForm extends AuthorForm
{
  
  public function configure()
  {
    parent::configure();
    unset($this['id']);
    
    $this->validatorSchema['first_name']->setOption('required', true);
    $this->validatorSchema['last_name']->setOption('required', true);
    
    $publicationsForm = new sfForm();
    foreach($this->getObject()->getPublications() as $publication)
    {
      $publicationsForm->embedForm('publication_'.$publication->getId(), new myPublicationForm($publication));
    }
    // add one blank publication form
    $publicationsForm->embedForm('new_1', new myPublicationForm());
    // embed the publication form
    $this->embedForm('publications', $publicationsForm);
    
    $this->widgetSchema->setNameFormat('author[%s]');
  }
  ...
}

class myPublicationForm extends PublicationForm
{
  public function configure()
  {
    parent::configure();
    
    unset(
      $this['author_id'],
      $this['id']
    );
  }
}

Your Main Form: sfFormPropel vs sfForm

Here it is:: sfFormPropel has the ability to automatically save the embedded forms, while sfForm does not. In this example, our main form (myAuthorForm) extends sfFormPropel, which actually makes our job a bit easier. Specifically, with sfForm we must add a save() method to manually save our underlying embedded forms. With sfPropelForm, we don't have to do anything - the save method is built in.
Saving embedded forms:

• sfForm Manually add a save() method
• sfFormPropel Do nothing, the save() method is built in

One little detail - making sure the publications have the right author

As I just explained, if your main form is an sfFormPropel form, then you need not do any extra work to save your embedded forms: it happens automatically.

However, in its current form, the Publication objects are being saved without an author_id (actually, an error is being thrown since that field is required in my schema). Somehow, we need to be able to set the author_id field of our publications before they are saved (but AFTER the author is saved, to ensure that it has an id). Here's the trick:

  /**
   * Update the author_id of the publications after the author has been saved
   */
  public function saveEmbeddedForms($con = null, $forms = null)
  {    
    foreach($this->embeddedForms['publications']->getEmbeddedForms() as $publicationForm)
    {
      if (!$publicationForm->getObject()->getAuthorId())
      {
        $publicationForm->getObject()->setAuthorId($this->getObject()->getId());
      }
    }
    
    parent::saveEmbeddedForms($con, $forms);
  }

The saveEmbeddedForms method is an sfFormPropel method that is called AFTER the object of the main form has been saved. It's very useful in this case because this guarantees that the author object has an id to use here.

Will I ever stop writing Symfony form articles???

Another post about the Symfony form framework: even I'm feeling a little exhausted. Still, through the expansion of the framework and books, blogs, and other articles, I'm now able to use the framework to easily do some pretty flexible and innovative tasks. So, I feel like we're getting somewhere.

But what else is there? What other problems and solutions have you run into? If the framework can't be used in all the most flexible ways, then it has failed. So far, it's doing pretty well imo.

Attachments