Skip to content

Commit 3e76637

Browse files
committed
minor #17962 [Form] Removed jQuery in favour of vanilla Javascript (jeromegxj)
This PR was submitted for the 6.2 branch but it was squashed and merged into the 5.4 branch instead. Discussion ---------- [Form] Removed jQuery in favour of vanilla Javascript I don't see any value to use jQuery in the `forms types collection` documentation. If I'm missing a point let me know, otherwise we can work on this PR to remove it ? <!-- If your pull request fixes a BUG, use the oldest maintained branch that contains the bug (see https://symfony.com/releases for the list of maintained branches). If your pull request documents a NEW FEATURE, use the same Symfony branch where the feature was introduced (and `6.x` for features of unreleased versions). --> Commits ------- 0faacd5 [Form] Removed jQuery in favour of vanilla Javascript
2 parents 0534532 + 0faacd5 commit 3e76637

File tree

1 file changed

+0
-108
lines changed

1 file changed

+0
-108
lines changed

reference/forms/types/collection.rst

Lines changed: 0 additions & 108 deletions
Original file line numberDiff line numberDiff line change
@@ -86,114 +86,6 @@ existing addresses. Adding new addresses is possible by using the `allow_add`_
8686
option (and optionally the `prototype`_ option) (see example below). Removing
8787
emails from the ``emails`` array is possible with the `allow_delete`_ option.
8888

89-
Adding and Removing Items
90-
~~~~~~~~~~~~~~~~~~~~~~~~~
91-
92-
If `allow_add`_ is set to ``true``, then if any unrecognized items are submitted,
93-
they'll be added seamlessly to the array of items. This is great in theory,
94-
but takes a little bit more effort in practice to get the client-side JavaScript
95-
correct.
96-
97-
Following along with the previous example, suppose you start with two
98-
emails in the ``emails`` data array. In that case, two input fields will
99-
be rendered that will look something like this (depending on the name of
100-
your form):
101-
102-
.. code-block:: html
103-
104-
<input type="email" id="form_emails_0" name="form[emails][0]" value="foo@foo.com"/>
105-
<input type="email" id="form_emails_1" name="form[emails][1]" value="bar@bar.com"/>
106-
107-
To allow your user to add another email, just set `allow_add`_ to ``true``
108-
and - via JavaScript - render another field with the name ``form[emails][2]``
109-
(and so on for more and more fields).
110-
111-
To help make this easier, setting the `prototype`_ option to ``true`` allows
112-
you to render a "template" field, which you can then use in your JavaScript
113-
to help you dynamically create these new fields. A rendered prototype field
114-
will look like this:
115-
116-
.. code-block:: html
117-
118-
<input type="email"
119-
id="form_emails___name__"
120-
name="form[emails][__name__]"
121-
value=""
122-
/>
123-
124-
By replacing ``__name__`` with some unique value (e.g. ``2``),
125-
you can build and insert new HTML fields into your form.
126-
127-
Using jQuery, a simple example might look like this. If you're rendering
128-
your collection fields all at once (e.g. ``form_row(form.emails)``), then
129-
things are even easier because the ``data-prototype`` attribute is rendered
130-
automatically for you (with a slight difference - see note below) and all
131-
you need is this JavaScript code:
132-
133-
.. code-block:: javascript
134-
135-
// add-collection-widget.js
136-
jQuery(document).ready(function () {
137-
jQuery('.add-another-collection-widget').click(function (e) {
138-
var list = jQuery(jQuery(this).attr('data-list-selector'));
139-
// Try to find the counter of the list or use the length of the list
140-
var counter = list.data('widget-counter') || list.children().length;
141-
142-
// grab the prototype template
143-
var newWidget = list.attr('data-prototype');
144-
// replace the "__name__" used in the id and name of the prototype
145-
// with a number that's unique to your emails
146-
// end name attribute looks like name="contact[emails][2]"
147-
newWidget = newWidget.replace(/__name__/g, counter);
148-
// Increase the counter
149-
counter++;
150-
// And store it, the length cannot be used if deleting widgets is allowed
151-
list.data('widget-counter', counter);
152-
153-
// create a new list element and add it to the list
154-
var newElem = jQuery(list.attr('data-widget-tags')).html(newWidget);
155-
newElem.appendTo(list);
156-
});
157-
});
158-
159-
And update the template as follows:
160-
161-
.. code-block:: html+twig
162-
163-
{{ form_start(form) }}
164-
{# ... #}
165-
166-
{# store the prototype on the data-prototype attribute #}
167-
<ul id="email-fields-list"
168-
data-prototype="{{ form_widget(form.emails.vars.prototype)|e }}"
169-
data-widget-tags="{{ '<li></li>'|e }}"
170-
data-widget-counter="{{ form.emails|length }}">
171-
{% for emailField in form.emails %}
172-
<li>
173-
{{ form_errors(emailField) }}
174-
{{ form_widget(emailField) }}
175-
</li>
176-
{% endfor %}
177-
</ul>
178-
179-
<button type="button"
180-
class="add-another-collection-widget"
181-
data-list-selector="#email-fields-list">Add another email</button>
182-
183-
{# ... #}
184-
{{ form_end(form) }}
185-
186-
<script src="add-collection-widget.js"></script>
187-
188-
.. tip::
189-
190-
If you're rendering the entire collection at once, then the prototype
191-
is automatically available on the ``data-prototype`` attribute of the
192-
element (e.g. ``div`` or ``table``) that surrounds your collection.
193-
The only difference is that the entire "form row" is rendered for you,
194-
meaning you wouldn't have to wrap it in any container element as it
195-
was done above.
196-
19789
Field Options
19890
-------------
19991

0 commit comments

Comments
 (0)