@@ -421,7 +421,7 @@ corresponding errors printed out with the form.
421
421
blank fields.
422
422
423
423
Validation is a very powerful feature of Symfony2 and has its own
424
- :doc: `dedicated chapter</book/validation> `.
424
+ :doc: `dedicated chapter </book/validation >`.
425
425
426
426
.. index ::
427
427
single: Forms; Validation groups
@@ -438,7 +438,7 @@ you'll need to specify which validation group(s) your form should use::
438
438
'validation_groups' => array('registration'),
439
439
))->add(...);
440
440
441
- If you're creating :ref: `form classes<book-form-creating-form-classes> ` (a
441
+ If you're creating :ref: `form classes <book-form-creating-form-classes >` (a
442
442
good practice), then you'll need to add the following to the ``setDefaultOptions() ``
443
443
method::
444
444
@@ -591,7 +591,7 @@ Field Type Options
591
591
592
592
Each field type has a number of options that can be used to configure it.
593
593
For example, the ``dueDate `` field is currently being rendered as 3 select
594
- boxes. However, the :doc: `date field</reference/forms/types/date> ` can be
594
+ boxes. However, the :doc: `date field </reference/forms/types/date >` can be
595
595
configured to be rendered as a single text box (where the user would enter
596
596
the date as a string in the box)::
597
597
@@ -610,7 +610,8 @@ the documentation for each type.
610
610
any field. By default, the ``required `` option is set to ``true ``, meaning
611
611
that HTML5-ready browsers will apply client-side validation if the field
612
612
is left blank. If you don't want this behavior, either set the ``required ``
613
- option on your field to ``false `` or :ref: `disable HTML5 validation<book-forms-html5-validation-disable> `.
613
+ option on your field to ``false `` or
614
+ :ref: `disable HTML5 validation <book-forms-html5-validation-disable >`.
614
615
615
616
Also note that setting the ``required `` option to ``true `` will **not **
616
617
result in server-side validation to be applied. In other words, if a
@@ -753,7 +754,7 @@ Take a look at each part:
753
754
754
755
* ``form_end() `` - Renders the end tag of the form and any fields that have not
755
756
yet been rendered. This is useful for rendering hidden fields and taking
756
- advantage of the automatic :ref: `CSRF Protection<forms-csrf> `.
757
+ advantage of the automatic :ref: `CSRF Protection <forms-csrf >`.
757
758
758
759
The majority of the work is done by the ``form_row `` helper, which renders
759
760
the label, errors and HTML form widget of each field inside a ``div `` tag
@@ -893,7 +894,7 @@ Twig Template Function Reference
893
894
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
894
895
895
896
If you're using Twig, a full reference of the form rendering functions is
896
- available in the :doc: `reference manual</reference/forms/twig_reference> `.
897
+ available in the :doc: `reference manual </reference/forms/twig_reference >`.
897
898
Read this to know everything about the helpers available and the options
898
899
that can be used with each.
899
900
@@ -1160,7 +1161,7 @@ HTML form and then translate user-submitted data back to the original object. As
1160
1161
such, the topic of persisting the ``Task`` object to the database is entirely
1161
1162
unrelated to the topic of forms. But, if you've configured the ``Task`` class
1162
1163
to be persisted via Doctrine (i.e. you've added
1163
- :ref:`mapping metadata<book-doctrine-adding-mapping>` for it), then persisting
1164
+ :ref:`mapping metadata <book-doctrine-adding-mapping>` for it), then persisting
1164
1165
it after a form submission can be done when the form is valid::
1165
1166
1166
1167
if ($form->isValid()) {
@@ -1176,7 +1177,7 @@ you can fetch it from the form::
1176
1177
1177
1178
$task = $form->getData();
1178
1179
1179
- For more information, see the :doc:`Doctrine ORM chapter</book/doctrine>`.
1180
+ For more information, see the :doc:`Doctrine ORM chapter </book/doctrine>`.
1180
1181
1181
1182
The key thing to understand is that when the form is submitted, the submitted
1182
1183
data is transferred to the underlying object immediately. If you want to
@@ -1339,7 +1340,7 @@ form with many ``Product`` sub-forms). This is done by using the ``collection``
1339
1340
field type.
1340
1341
1341
1342
For more information see the " :doc:`/cookbook/form/form_collections`" cookbook
1342
- entry and the :doc:`collection</reference/forms/types/collection>` field type reference.
1343
+ entry and the :doc:`collection </reference/forms/types/collection>` field type reference.
1343
1344
1344
1345
.. index::
1345
1346
single: Forms; Theming
@@ -1522,7 +1523,7 @@ override the default error rendering for *all* fields, copy and customize the
1522
1523
.. tip::
1523
1524
1524
1525
The " parent" type of each field type is available in the
1525
- :doc:`form type reference</reference/forms/types>` for each field type.
1526
+ :doc:`form type reference </reference/forms/types>` for each field type.
1526
1527
1527
1528
.. index::
1528
1529
single: Forms; Global Theming
@@ -1812,7 +1813,7 @@ simple array of your submitted data, how can you add constraints to the data of
1812
1813
your form?
1813
1814
1814
1815
The answer is to setup the constraints yourself, and attach them to the individual
1815
- fields. The overall approach is covered a bit more in the :ref:`validation chapter<book-validation-raw-values>`,
1816
+ fields. The overall approach is covered a bit more in the :ref:`validation chapter <book-validation-raw-values>`,
1816
1817
but here's a short example:
1817
1818
1818
1819
.. versionadded:: 2.1
@@ -1857,12 +1858,12 @@ HTML form so that the user can modify that data. The second goal of a form is to
1857
1858
take the data submitted by the user and to re-apply it to the object.
1858
1859
1859
1860
There's still much more to learn about the powerful world of forms, such as
1860
- how to handle :doc:`file uploads with Doctrine
1861
- </cookbook/doctrine/file_uploads>` or how to create a form where a dynamic
1862
- number of sub-forms can be added (e.g. a todo list where you can keep adding
1863
- more fields via Javascript before submitting). See the cookbook for these
1864
- topics. Also, be sure to lean on the
1865
- :doc:`field type reference documentation</reference/forms/types>`, which
1861
+ how to handle
1862
+ :doc:`file uploads with Doctrine </cookbook/doctrine/file_uploads>` or how
1863
+ to create a form where a dynamic number of sub-forms can be added (e.g. a
1864
+ todo list where you can keep adding more fields via Javascript before submitting).
1865
+ See the cookbook for these topics. Also, be sure to lean on the
1866
+ :doc:`field type reference documentation </reference/forms/types>`, which
1866
1867
includes examples of how to use each field type and its options.
1867
1868
1868
1869
Learn more from the Cookbook
0 commit comments