Symfony2: Adding a collection based on a table-inheritance structure to a FormView

Question

I am working on a Symfony2/Doctrine app which uses class-table-inheritance (http://docs.doctrine-project.org/en/2.0.x/reference/inheritance-mapping.html#class-table-inheritance) to manage Complaints in a Consult. Each Consult can have many Complaints (OneToMany), and each different type of Complaint has a different structure and appearance. Complaints are a collection and are added dynamically with JS.

At this point, I am able to persist the Complaints and link them to the Consults by recasting them as the appropriate types in the Controller before persistence. I have run into some issues with this and I'm planning on migrating this to a form event (http://symfony.com/doc/current/cookbook/form/dynamic_form_generation.html) or something of that nature to streamline the process.

The problem that I am running into at this point, however, is that I am unable to display existing Complaints in a view using the FormView because the form builder demands that I set the type of the collection to be displayed. If each Consult had only one type of Complaint, that would be fine, but they can have multiple types, and setting the type in the form builder limits me to that one type.

Is there some approach that I can take to stop the FormView from tyring to convert to string in the absence of a type or some way to dynamically detect and assign the type on a per-Complaint basis (using $complaint->getComplaintType(), perhaps)?

<?php
namespace Acme\ConsultBundle\Entity;
class Consult
{
    /**
     * @ORM\OneToMany(targetEntity="Acme\ConsultBundle\Entity\ComplaintBase", mappedBy="consult", cascade={"persist", "remove"})
     */
    protected $complaints;
}
?>


<?php
namespace Acme\ConsultBundle\Entity;
/**
 * Acme\ConsultBundle\Entity\ConsultBase
 *
 * @ORM\Entity
 * @ORM\Table(name="ConsultComplaintBase")
 * @ORM\HasLifecycleCallbacks
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="complaint_name", type="string")
 * @ORM\DiscriminatorMap({
 *  "ComplaintDefault"      = "Acme\ConsultBundle\Entity\ComplaintDefault",
 *  "ComplaintRosacea"      = "Acme\ConsultBundle\Entity\ComplaintRosacea",
 *  "ComplaintBotox"        = "Acme\ConsultBundle\Entity\ComplaintBotox",
 *  "ComplaintAcne"         = "Acme\ConsultBundle\Entity\ComplaintAcne",
 *  "ComplaintUrticaria"    = "Acme\ConsultBundle\Entity\ComplaintUrticaria",
 * })
 */
abstract class ComplaintBase
{
    /**
     * @ORM\ManyToOne(targetEntity="Acme\ConsultBundle\Entity\Consult", inversedBy="complaints")
     * @ORM\JoinColumn(name="consult_id", referencedColumnName="id")
     */
    protected $consult;
    /**
     * @ORM\Column(type="string", length="255")
     */
    protected $complaintType;
}
?>


<?php
namespace Acme\ConsultBundle\Form\Type;
class ConsultType extends AbstractType
{
    public function buildForm(FormBuilder $builder, array $options)
    {
        $builder
            ->add('complaints', 'collection', array(
                // 'type' => new ComplaintUrticariaType(),
                'error_bubbling' => true,
                'allow_add' => true,
                'allow_delete' => true,
                'by_reference' => false,
            ));
    }
}
?>

Kapok

I'm running into the exact same issue. Did you find any solution? – Culminate

I ended up doing the same kind of thing I was doing when persisiting the Complaints (the JOINed entity). I'm then passing an array of the recast Complaints into the template for rendering. This approach uses more DB calls than I'd prefer. – Kapok

Answer 1

Not exactly sure that it will work with the collection, but it certainly works with a single form. Please try this idea.

First make a form for your basic entity ComplaintBase

class ComplaintForm extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $subscriber = new ComplaintSubscriber($builder);
        $builder->addEventSubscriber($subscriber);

        /* your fields */ 
    }

    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array(
            'data_class' => 'Acme\ConsultBundle\Entity\ComplaintBase',
        ));
    }
}

Then in subscriber you can define additional fields based on submitted entity type.

class ComplaintSubscriber implements EventSubscriberInterface
{
    private $factory;
    private $builder;

    public function __construct(FormBuilderInterface $builder)
    {
        $this->factory = $builder->getFormFactory();
        $this->builder = $builder;
    }

    public static function getSubscribedEvents()
    {
        return array(
            FormEvents::PRE_SET_DATA => 'preSetData',
        );
    }

    public function preSetData(FormEvent $event)
    {
        $data = $event->getData();
        $form = $event->getForm();

        if (null === $data) {
            return;
        }

        $class = get_class($data);
        if( $class === 'Acme\ConsultBundle\Entity\ComplaintDefault' ) {
            $this->processDefault($data, $form);
        }
        elseif( $class === 'Acme\ConsultBundle\Entity\ComplaintRosacea' ) {
            $this->processRosacea($data, $form);
        }
        elseif( $class === 'Acme\ConsultBundle\Entity\ComplaintBotox' ) {
            $this->processBotox($data, $form);
        }
        else {
            #NOP
        }
    }

    protected function processDefault(Entity\ComplaintDefault $node, FormInterface &$form)
    {
        #NOP
    }

    protected function processRosacea(Entity\ComplaintRosacea $node, FormInterface &$form)
    {
        $form->add($this->factory->createNamed('some_field', 'text'));
    }

    protected function processBotox(Entity\ComplaintBotox $node, FormInterface &$form)
    {
        $form->add($this->factory->createNamed('other_field', 'text'));
    }
}

Automata

This feels like a very restrictive approach, every time you want to add a new table to the group you would need to add a new if statement and a new function. An approach using the collection type like this: forum.symfony-project.org/viewtopic.php?f=23&t=37873 is a much more configurable solution. I would steer away from hardcoding class names in code that you might want to be reusable. You could not, for instance, use your subscriber for another instance of cti and would have to create another almost identical one – Jobbery

This is just an idea, not a complete solution. Of course you can go through all the fields of a class and add to the form. But if the fields that do not need to add? Make your annotations, settings and so on ... – Automata