@@ -235,7 +235,7 @@ zero tags when first created).
235235
236236 <!-- ... -->
237237
238- When the user submits the form, the submitted data for the ``Tags ``fields are
238+ When the user submits the form, the submitted data for the ``tags ``field are
239239used to construct an ``ArrayCollection `` of ``Tag `` objects, which is then set
240240on the ``tag `` field of the ``Task `` instance.
241241
@@ -293,54 +293,6 @@ add the ``allow_add`` option to your collection field::
293293 ));
294294 }
295295
296- Now that the form type knows tags can be added, the ``Tasks `` class needs to
297- add methods to make editing the tags possible. This is done by creating an
298- "adder". In this case, the adder will be ``addTag ``::
299-
300- // src/Acme/TaskBundle/Entity/Task.php
301- namespace Acme\TaskBundle\Entity;
302-
303- // ...
304- class Task
305- {
306- // ...
307-
308- public function addTag($tag)
309- {
310- $this->tags->add($tag);
311- }
312-
313- public function removeTag($tag)
314- {
315- // ...
316- }
317- }
318-
319- But, the form type will still use ``getTags `` now. You need to set the
320- ``by_reference `` option to ``false ``, otherwise the form type will get the
321- object by using the getter and change that object.
322-
323- ..caution ::
324-
325- If no ``addTag `` **and ** ``removeTag `` method is found, the form will
326- still ``setTag `` when setting ``by_reference `` to ``false ``. You'll learn
327- more about the ``removeTag `` method later in this article.
328-
329- ..code-block ::php
330-
331- // src/Acme/TaskBundle/Form/Type/TaskType.php
332-
333- // ...
334- public function buildForm(FormBuilderInterface $builder, array $options)
335- {
336- // ...
337-
338- $builder->add('tags', 'collection', array(
339- // ...
340- 'by_reference' => false,
341- ));
342- }
343-
344296In addition to telling the field to accept any number of submitted objects, the
345297``allow_add `` also makes a *"prototype" * variable available to you. This "prototype"
346298is a little "template" that contains all the HTML to be able to render any
@@ -465,6 +417,56 @@ Now, each time a user clicks the ``Add a tag`` link, a new sub form will
465417appear on the page. When the form is submitted, any new tag forms will be converted
466418into new ``Tag `` objects and added to the ``tags `` property of the ``Task `` object.
467419
420+ To make handling these new tags easier, add an "adder" and a "remover" method
421+ for the tags in the ``Task `` class::
422+
423+ // src/Acme/TaskBundle/Entity/Task.php
424+ namespace Acme\TaskBundle\Entity;
425+
426+ // ...
427+ class Task
428+ {
429+ // ...
430+
431+ public function addTag($tag)
432+ {
433+ $this->tags->add($tag);
434+ }
435+
436+ public function removeTag($tag)
437+ {
438+ // ...
439+ }
440+ }
441+
442+ Next, add a ``by_reference `` option to the ``tags `` field and set it to ``false ``::
443+
444+ // src/Acme/TaskBundle/Form/Type/TaskType.php
445+
446+ // ...
447+ public function buildForm(FormBuilderInterface $builder, array $options)
448+ {
449+ // ...
450+
451+ $builder->add('tags', 'collection', array(
452+ // ...
453+ 'by_reference' => false,
454+ ));
455+ }
456+
457+ With these two changes, when the form is submitted, each new ``Tag `` object
458+ is added to the ``Task `` class by calling the ``addTag `` method. Before this
459+ change, they were added internally by the form by calling ``$task->getTags()->add($task) ``.
460+ That was just fine, but forcing the use of the "adder" method makes handling
461+ these new ``Tag `` objects easier (especially if you're using Doctrine, which
462+ we talk about next!).
463+
464+ ..caution ::
465+
466+ If no ``addTag `` **and ** ``removeTag `` method is found, the form will
467+ still use ``setTag `` even if ``by_reference `` is ``false ``. You'll learn
468+ more about the ``removeTag `` method later in this article.
469+
468470..sidebar ::Doctrine: Cascading Relations and saving the "Inverse" side
469471
470472 To save the new tags with Doctrine, you need to consider a couple more