..note::

<!-- ... -->

When the user submits the form, the submitted data for the ``Tags`` fields

areused to construct an ArrayCollection of ``Tag`` objects, which is then

seton the ``tag`` field of the ``Task`` instance.

When the user submits the form, the submitted data for the ``Tags`` fields are

used to construct an``ArrayCollection`` of ``Tag`` objects, which is then set

on the ``tag`` field of the ``Task`` instance.

The ``Tags`` collection is accessible naturally via ``$task->getTags()``

and can be persisted to the database or used however you need.

Note that ``'by_reference' => false`` was also added. Normally, the form

framework would modify the tags on a `Task` object *without* actually

ever calling `setTags`. By setting:ref:`by_reference<reference-form-types-by-reference>`

to `false`, `setTags` will be called. This will be important later as you'll

see.

Now that the form type knows tags can be added, the ``Tasks`` class needs to

add methods to make editing the tags possible. This is done by creating an

"adder". In this case, the adder will be ``addTag``::

But, the form type will still use ``getTags`` now. You need to set the

``by_reference`` option to ``false``, otherwise the form type will get the

object by using the getter and change that object.

..caution::

If no ``addTag`` **and** ``removeTag`` method is found, the form will

still ``setTag`` when setting ``by_reference`` to ``false``. You'll learn

more about the ``removeTag`` method later in this article.

..code-block::php

In addition to telling the field to accept any number of submitted objects, the

``allow_add`` also makes a "prototype" variable available to you. This "prototype"

``allow_add`` also makes a*"prototype"* variable available to you. This "prototype"

is a little "template" that contains all the HTML to be able to render any

new "tag" forms. To render it, make the following change to your template:

..code-block::html+php

<ul class="tags" data-prototype="<?php echo $view->escape($view['form']->row($form['tags']->vars['prototype'])) ?>">

<ul class="tags" data-prototype="<?php

echo $view->escape($view['form']->row($form['tags']->vars['prototype']))

?>">

...

</ul>

..sidebar::Doctrine: Cascading Relations and saving the "Inverse" side

Toget the new tagsto save inDoctrine, you need to consider a couple

morethings. First, unless you iterate over all of the new ``Tag`` objects

andcall ``$em->persist($tag)`` on each, you'll receive an error from

Tosave the new tagswithDoctrine, you need to consider a couple more

things. First, unless you iterate over all of the new ``Tag`` objects and

call ``$em->persist($tag)`` on each, you'll receive an error from

Doctrine:

A new entity was found through the relationship `Acme\TaskBundle\Entity\Task#tags`

that was not configured to cascade persist operations for entity...

A new entity was found through the relationship

``Acme\TaskBundle\Entity\Task#tags`` that was not configured to

cascade persist operations for entity...

To fix this, you may choose to "cascade" the persist operation automatically

from the ``Task`` object to any related tags. To do this, add the ``cascade``

of the relationship is modified.

The trick is to make sure that the single "Task" is set on each "Tag".

One easy way to do this is to add some extra logic to ``setTags()``,

which is called by the formframework since:ref:`by_reference<reference-form-types-by-reference>`

is set to``false``::

One easy way to do this is to add some extra logic to ``addTag()``,

which is called by the formtype since``by_reference`` is set to

``false``::

Inside ``Tag``, just make sure you have an ``addTask`` method::

If you have a ``OneToMany`` relationship, then the workaround is similar,

except that you can simply call ``setTask`` from inside ``setTags``.

except that you can simply call ``setTask`` from inside ``addTag``.

.. _cookbook-form-collections-remove:

Now, you need to put some code into the ``removeTag`` method of ``Task``::

Templates Modifications

..sidebar::Doctrine: Ensuring the database persistence

When removing objects in this way, you may need to do a little bit more

work to ensure that the relationship between the Task and the removed Tag

is properly removed.

work to ensure that the relationship between the``Task`` and the removed

``Tag``is properly removed.

In Doctrine, you have two side of the relationship: the owning side and the

inverse side. Normally in this case you'll have a ManyToMany relation

inverse side. Normally in this case you'll have a``ManyToMany`` relation

and the deleted tags will disappear and persist correctly (adding new

tags also works effortlessly).