4
4
collection Field Type
5
5
=====================
6
6
7
- This field type is used to render a "collection" of some field or form. In
8
- the easiest sense, it could be an array of ``text `` fields that populate
7
+ This field type is used to render a "collection" of some field or form.
8
+ In the easiest sense, it could be an array of ``text `` fields that populate
9
9
an array ``emails `` field. In more complex examples, you can embed entire
10
- forms, which is useful when creating forms that expose one-to-many relationships
11
- (e.g. a product from where you can manage many related product photos).
10
+ forms, which is useful when creating forms that expose one-to-many
11
+ relationships (e.g. a product from where you can manage many related product
12
+ photos).
12
13
13
14
+-------------+-----------------------------------------------------------------------------+
14
15
| Rendered as | depends on the `type `_ option |
@@ -45,8 +46,8 @@ forms, which is useful when creating forms that expose one-to-many relationships
45
46
Basic Usage
46
47
-----------
47
48
48
- This type is used when you want to manage a collection of similar items in
49
- a form. For example, suppose you have an ``emails `` field that corresponds
49
+ This type is used when you want to manage a collection of similar items
50
+ in a form. For example, suppose you have an ``emails `` field that corresponds
50
51
to an array of email addresses. In the form, you want to expose each email
51
52
address as its own input text box::
52
53
@@ -104,8 +105,8 @@ A much more flexible method would look like this:
104
105
<?php endforeach ?>
105
106
</ul>
106
107
107
- In both cases, no input fields would render unless your ``emails `` data array
108
- already contained some emails.
108
+ In both cases, no input fields would render unless your ``emails `` data
109
+ array already contained some emails.
109
110
110
111
In this simple example, it's still impossible to add new addresses or remove
111
112
existing addresses. Adding new addresses is possible by using the `allow_add `_
@@ -141,7 +142,11 @@ will look like this:
141
142
142
143
.. code-block :: html
143
144
144
- <input type =" email" id =" form_emails___name__" name =" form[emails][__name__]" value =" " />
145
+ <input type =" email"
146
+ id =" form_emails___name__"
147
+ name =" form[emails][__name__]"
148
+ value =" "
149
+ />
145
150
146
151
By replacing ``__name__ `` with some unique value (e.g. ``2 ``),
147
152
you can build and insert new HTML fields into your form.
@@ -160,7 +165,8 @@ you need is the JavaScript:
160
165
{# ... #}
161
166
162
167
{# store the prototype on the data-prototype attribute #}
163
- <ul id="email-fields-list" data-prototype="{{ form_widget(form.emails.vars.prototype)|e }}">
168
+ <ul id="email-fields-list"
169
+ data-prototype="{{ form_widget(form.emails.vars.prototype)|e }}">
164
170
{% for emailField in form.emails %}
165
171
<li>
166
172
{{ form_errors(emailField) }}
@@ -203,10 +209,10 @@ you need is the JavaScript:
203
209
204
210
If you're rendering the entire collection at once, then the prototype
205
211
is automatically available on the ``data-prototype `` attribute of the
206
- element (e.g. ``div `` or ``table ``) that surrounds your collection. The
207
- only difference is that the entire "form row" is rendered for you, meaning
208
- you wouldn't have to wrap it in any container element as it was done
209
- above.
212
+ element (e.g. ``div `` or ``table ``) that surrounds your collection.
213
+ The only difference is that the entire "form row" is rendered for you,
214
+ meaning you wouldn't have to wrap it in any container element as it
215
+ was done above.
210
216
211
217
Field Options
212
218
-------------
@@ -222,8 +228,9 @@ items as well as the new item that was in the submitted data. See the above
222
228
example for more details.
223
229
224
230
The `prototype `_ option can be used to help render a prototype item that
225
- can be used - with JavaScript - to create new form items dynamically on the
226
- client side. For more information, see the above example and :ref: `cookbook-form-collections-new-prototype `.
231
+ can be used - with JavaScript - to create new form items dynamically on
232
+ the client side. For more information, see the above example and
233
+ :ref: `cookbook-form-collections-new-prototype `.
227
234
228
235
.. caution ::
229
236
@@ -249,11 +256,11 @@ For more information, see :ref:`cookbook-form-collections-remove`.
249
256
250
257
Be careful when using this option when you're embedding a collection
251
258
of objects. In this case, if any embedded forms are removed, they *will *
252
- correctly be missing from the final array of objects. However, depending on
253
- your application logic, when one of those objects is removed, you may want
254
- to delete it or at least remove its foreign key reference to the main object.
255
- None of this is handled automatically. For more information, see
256
- :ref: `cookbook-form-collections-remove `.
259
+ correctly be missing from the final array of objects. However, depending
260
+ on your application logic, when one of those objects is removed, you
261
+ may want to delete it or at least remove its foreign key reference to
262
+ the main object. None of this is handled automatically. For more
263
+ information, see :ref: `cookbook-form-collections-remove `.
257
264
258
265
options
259
266
~~~~~~~
@@ -262,8 +269,9 @@ options
262
269
263
270
This is the array that's passed to the form type specified in the `type `_
264
271
option. For example, if you used the :doc: `choice </reference/forms/types/choice >`
265
- type as your `type `_ option (e.g. for a collection of drop-down menus), then
266
- you'd need to at least pass the ``choices `` option to the underlying type::
272
+ type as your `type `_ option (e.g. for a collection of drop-down menus),
273
+ then you'd need to at least pass the ``choices `` option to the underlying
274
+ type::
267
275
268
276
$builder->add('favorite_cities', 'collection', array(
269
277
'type' => 'choice',
@@ -283,13 +291,13 @@ prototype
283
291
**type **: ``boolean `` **default **: ``true ``
284
292
285
293
This option is useful when using the `allow_add `_ option. If ``true `` (and
286
- if `allow_add `_ is also ``true ``), a special "prototype" attribute will be
287
- available so that you can render a "template" example on your page of what
288
- a new element should look like. The ``name `` attribute given to this element
289
- is ``__name__ ``. This allows you to add a "add another" button via JavaScript
290
- which reads the prototype, replaces ``__name__ `` with some unique name or
291
- number, and render it inside your form. When submitted, it will be added
292
- to your underlying array due to the `allow_add `_ option.
294
+ if `allow_add `_ is also ``true ``), a special "prototype" attribute will
295
+ be available so that you can render a "template" example on your page of
296
+ what a new element should look like. The ``name `` attribute given to this
297
+ element is ``__name__ ``. This allows you to add a "add another" button via
298
+ JavaScript which reads the prototype, replaces ``__name__ `` with some unique
299
+ name or number and render it inside your form. When submitted, it will
300
+ be added to your underlying array due to the `allow_add `_ option.
293
301
294
302
The prototype field can be rendered via the ``prototype `` variable in the
295
303
collection field:
@@ -313,34 +321,35 @@ rendering your form, having the entire "form row" may be easier for you.
313
321
form row is automatically available on the ``data-prototype `` attribute
314
322
of the element (e.g. ``div `` or ``table ``) that surrounds your collection.
315
323
316
- For details on how to actually use this option, see the above example as well
317
- as :ref: `cookbook-form-collections-new-prototype `.
324
+ For details on how to actually use this option, see the above example as
325
+ well as :ref: `cookbook-form-collections-new-prototype `.
318
326
319
327
prototype_name
320
328
~~~~~~~~~~~~~~
321
329
322
330
**type **: ``String `` **default **: ``__name__ ``
323
331
324
332
If you have several collections in your form, or worse, nested collections
325
- you may want to change the placeholder so that unrelated placeholders are not
326
- replaced with the same value.
333
+ you may want to change the placeholder so that unrelated placeholders are
334
+ not replaced with the same value.
327
335
328
336
type
329
337
~~~~
330
338
331
339
**type **: ``string `` or :class: `Symfony\\ Component\\ Form\\ FormTypeInterface ` **required **
332
340
333
- This is the field type for each item in this collection (e.g. ``text ``, `` choice ``,
334
- etc). For example, if you have an array of email addresses, you'd use the
335
- :doc: `email </reference/forms/types/email >` type. If you want to embed
336
- a collection of some other form, create a new instance of your form type
337
- and pass it as this option.
341
+ This is the field type for each item in this collection (e.g. ``text ``,
342
+ `` choice ``, etc). For example, if you have an array of email addresses,
343
+ you'd use the :doc: `email </reference/forms/types/email >` type. If you want
344
+ to embed a collection of some other form, create a new instance of your
345
+ form type and pass it as this option.
338
346
339
347
Inherited Options
340
348
-----------------
341
349
342
- These options inherit from the :doc: `form </reference/forms/types/form >` type.
343
- Not all options are listed here - only the most applicable to this type:
350
+ These options inherit from the :doc: `form </reference/forms/types/form >`
351
+ type. Not all options are listed here - only the most applicable to this
352
+ type:
344
353
345
354
.. _reference-form-types-by-reference :
346
355
0 commit comments