@@ -262,7 +262,7 @@ great, your user can't actually add any new tags yet.
262262.. _cookbook-form-collections-new-prototype :
263263
264264Allowing "new" Tags with the "Prototype"
265- -----------------------------------------
265+ ----------------------------------------
266266
267267Allowing the user to dynamically add new tags means that you'll need to
268268use some JavaScript. Previously you added two tags to your form in the controller.
@@ -417,6 +417,11 @@ into new ``Tag`` objects and added to the ``tags`` property of the ``Task`` obje
417417
418418 You can find a working example in this `JSFiddle `_.
419419
420+ .. seealso ::
421+
422+ If you want to customize the HTML code in the prototype, read
423+ :ref: `cookbook-form-custom-prototype `.
424+
420425To make handling these new tags easier, add an "adder" and a "remover" method
421426for the tags in the ``Task `` class::
422427
@@ -729,75 +734,5 @@ the relationship between the removed ``Tag`` and ``Task`` object.
729734 updated (whether you're adding new tags or removing existing tags) on
730735 each Tag object itself.
731736
732- .. _cookbook-form-collections-custom-prototype :
733-
734- Rendering a Custom Prototype
735- ----------------------------
736-
737- Most of the time the provided prototype will be sufficient for your needs
738- and does not need to be changed. But if you are in the situation were you
739- need to have a complete custom prototype, you can render it yourself.
740-
741- The Form component automatically looks for a block whose name follows a certain
742- schema to decide how to render each entry of the form type collection. For
743- example, if your form field is named ``tasks ``, you will be able to change
744- the widget for each task as follows:
745-
746- .. configuration-block ::
747-
748- .. code-block :: html+jinja
749-
750- {% form_theme form _self %}
751-
752- {% block _tasks_entry_widget %}
753- <tr>
754- <td>{{ form_widget(task.task) }}</td>
755- <td>{{ form_widget(task.dueDate) }}</td>
756- </tr>
757- {% endblock %}
758-
759- .. code-block :: html+php
760-
761- <!-- src/AppBundle/Resources/views/Form/_tasks_entry_widget.html.php -->
762- <tr>
763- <td><?php echo $view['form']->widget($form->task) ?></td>
764- <td><?php echo $view['form']->widget($form->dueDate) ?></td>
765- </tr>
766-
767- Not only can you override the rendered widget, but you can also change the
768- complete form row or the label as well. For the ``tasks `` field given above,
769- the block names would be the following:
770-
771- ================ =======================
772- Part of the Form Block Name
773- ================ =======================
774- ``label `` ``_tasks_entry_label ``
775- ``widget `` ``_tasks_entry_widget ``
776- ``row `` ``_tasks_entry_row ``
777- ================ =======================
778-
779- Then, you only have to ensure to render the collection type's ``data-prototype ``
780- property with the proper prototype so that new entries will be rendered the
781- same way as existing ones:
782-
783- .. configuration-block ::
784-
785- .. code-block :: html+jinja
786-
787- {% form_theme form _self %}
788-
789- {% block _tasks_widget %}
790- {% set attr = attr|merge({ 'data-prototype': form_row(prototype) }) %}
791- <table {{ block('widget_container_attributes') }}>
792- {% for child in form %}
793- {{ form_row(child) }}
794- {% endfor %}
795- </table>
796- {% endblock %}
797-
798- .. code-block :: html+php
799-
800- <!-- src/AppBundle/Resources/views/Form/_tasks_widget.html.php -->
801-
802737.. _`Owning Side and Inverse Side` : http://docs.doctrine-project.org/en/latest/reference/unitofwork-associations.html
803738.. _`JSFiddle` : http://jsfiddle.net/847Kf/4/
0 commit comments