8000 Fixes due to docbot linting docs · symfony/symfony-docs@74267cd · GitHub
[go: up one dir, main page]
Skip to content

Commit 74267cd

Browse files
wouterjwouterj
committed
Fixes due to docbot linting docs
1 parent 68db46c commit 74267cd

File tree

6 files changed

+78
-58
lines changed

6 files changed

+78
-58
lines changed

‎reference/constraints/Length.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -115,9 +115,9 @@ min
115115
This required option is the "min" length value. Validation will fail if
116116
the given value's length is **less** than this min value.
117117

118-
It is important to notice that NULL values and empty strings are considered
119-
valid no matter if the constraint required a minimum length. Validators are
120-
triggered only if the value is not blank.
118+
It is important to notice that NULL values and empty strings are considered
119+
valid no matter if the constraint required a minimum length. Validators
120+
are triggered only if the value is not blank.
121121

122122
max
123123
~~~

‎reference/constraints/NotBlank.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
NotBlank
22
========
33

4-
Validates that a value is not blank, defined as not strictly ``false``, not
5-
equal to a blank string and also not equal to ``null``. To force that a value
6-
is simply not equal to ``null``, see the :doc:`/reference/constraints/NotNull`
7-
constraint.
4+
Validates that a value is not blank, defined as not strictly ``false``,
5+
not equal to a blank string and also not equal to ``null``. To force that
6+
a value is simply not equal to ``null``, see the
7+
:doc:`/reference/constraints/NotNull` constraint.
88

99
+----------------+------------------------------------------------------------------------+
1010
| Applies to | :ref:`property or method <validation-property-target>` |

‎reference/forms/twig_reference.rst

Lines changed: 55 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -4,25 +4,27 @@
44
Twig Template Form Function and Variable Reference
55
==================================================
66

7-
When working with forms in a template, there are two powerful things at your
8-
disposal:
7+
When working with forms in a template, there are two powerful things at
8+
your disposal:
99

10-
* :ref:`Functions <reference-form-twig-functions>` for rendering each part of a form
11-
* :ref:`Variables <twig-reference-form-variables>` for getting *any* information about any field
10+
* :ref:`Functions <reference-form-twig-functions>` for rendering each part
11+
of a form;
12+
* :ref:`Variables <twig-reference-form-variables>` for getting *any* information
13+
about any field.
1214

1315
You'll use functions often to render your fields. Variables, on the other
1416
hand, are less commonly-used, but infinitely powerful since you can access
15-
a fields label, id attribute, errors, and anything else about the field.
17+
a fields label, id attribute, errors and anything else about the field.
1618

1719
.. _reference-form-twig-functions:
1820

1921
Form Rendering Functions
2022
------------------------
2123

2224
This reference manual covers all the possible Twig functions available for
23-
rendering forms. There are several different functions available, and each
24-
is responsible for rendering a different part of a form (e.g. labels, errors,
25-
widgets, etc).
25+
rendering forms. There are several different functions available and
26+
each is responsible for rendering a different part of a form (e.g. labels,
27+
errors, widgets, etc).
2628

2729
.. _reference-forms-twig-form:
2830

@@ -76,8 +78,8 @@ Renders the end tag of a form.
7678
7779
{{ form_end(form) }}
7880
79-
This helper also outputs ``form_rest()`` unless you set ``render_rest`` to
80-
false:
81+
This helper also outputs ``form_rest()`` unless you set ``render_rest``
82+
to false:
8183

8284
.. code-block:: jinja
8385
@@ -98,7 +100,11 @@ label you want to display as the second argument.
98100
99101
{# The two following syntaxes are equivalent #}
100102
{{ form_label(form.name, 'Your Name', {'label_attr': {'class': 'foo'}}) }}
101-
{{ form_label(form.name, null, {'label': 'Your name', 'label_attr': {'class': 'foo'}}) }}
103+
104+
{{ form_label(form.name, null, {
105+
'label': 'Your name',
106+
'label_attr': {'class': 'foo'}
107+
}) }}
102108
103109
See ":ref:`twig-reference-form-variables`" to learn about the ``variables``
104110
argument.
@@ -122,8 +128,8 @@ Renders any errors for the given field.
122128
form_widget(view, variables)
123129
----------------------------
124130

125-
Renders the HTML widget of a given field. If you apply this to an entire form
126-
or collection of fields, each underlying form row will be rendered.
131+
Renders the HTML widget of a given field. If you apply this to an entire
132+
form or collection of fields, each underlying form row will be rendered.
127133

128134
.. code-block:: jinja
129135
@@ -181,8 +187,8 @@ form_enctype(view)
181187

182188
.. note::
183189

184-
This helper was deprecated in Symfony 2.3 and will be removed in Symfony 3.0.
185-
You should use ``form_start()`` instead.
190+
This helper was deprecated in Symfony 2.3 and will be removed in Symfony
191+
3.0. You should use ``form_start()`` instead.
186192

187193
If the form contains at least one file upload field, this will render the
188194
required ``enctype="multipart/form-data"`` form attribute. It's always a
@@ -204,7 +210,8 @@ selectedchoice(selected_value)
204210
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
205211

206212
This test will check if the current choice is equal to the ``selected_value``
207-
or if the current choice is in the array (when ``selected_value`` is an array).
213+
or if the current choice is in the array (when ``selected_value`` is an
214+
array).
208215

209216
.. code-block:: jinja
210217
@@ -221,7 +228,7 @@ More about Form Variables
221228

222229
In almost every Twig function above, the final argument is an array of "variables"
223230
that are used when rendering that one part of the form. For example, the
224-
following would render the "widget" for a field, and modify its attributes
231+
following would render the "widget" for a field and modify its attributes
225232
to include a special class:
226233

227234
.. code-block:: jinja
@@ -242,41 +249,52 @@ Look at the ``form_label`` as an example:
242249
{% if not compound %}
243250
{% set label_attr = label_attr|merge({'for': id}) %}
244251
{% endif %}
252+
245253
{% if required %}
246-
{% set label_attr = label_attr|merge({'class': (label_attr.class|default('') ~ ' required')|trim}) %}
254+
{% set label_attr = label_attr|merge({
255+
'class': (label_attr.class|default('') ~ ' required')|trim
256+
}) %}
247257
{% endif %}
258+
248259
{% if label is empty %}
249260
{% set label = name|humanize %}
250261
{% endif %}
251-
<label{% for attrname, attrvalue in label_attr %} {{ attrname }}="{{ attrvalue }}"{% endfor %}>{{ label|trans({}, translation_domain) }}</label>
262+
263+
<label
264+
{% for attrname, attrvalue in label_attr -%}
265+
{{ attrname }}="{{ attrvalue }}"
266+
{%- endfor %}
267+
>
268+
{{ label|trans({}, translation_domain) }}
269+
</label>
252270
{% endblock form_label %}
253271
254-
This block makes use of several variables: ``compound``, ``label_attr``, ``required``,
255-
``label``, ``name`` and ``translation_domain``.
256-
These variables are made available by the form rendering system. But more
257-
importantly, these are the variables that you can override when calling ``form_label``
258-
(since in this example, you're rendering the label).
272+
This block makes use of several variables: ``compound``, ``label_attr``,
273+
``required``, ``label``, ``name`` and ``translation_domain``. These variables
274+
are made available by the form rendering system. But more importantly, these
275+
are the variables that you can override when calling ``form_label`` (since
276+
in this example, you're rendering the label).
259277

260278
The exact variables available to override depends on which part of the form
261279
you're rendering (e.g. label versus widget) and which field you're rendering
262-
(e.g. a ``choice`` widget has an extra ``expanded`` option). If you get comfortable
263-
with looking through `form_div_layout.html.twig`_, you'll always be able
264-
to see what options you have available.
280+
(e.g. a ``choice`` widget has an extra ``expanded`` option). If you get
281+
comfortable with looking through `form_div_layout.html.twig`_, you'll always
282+
be able to see what options you have available.
265283

266284
.. tip::
267285

268286
Behind the scenes, these variables are made available to the ``FormView``
269-
object of your form when the Form component calls ``buildView`` and ``finishView``
270-
on each "node" of your form tree. To see what "view" variables a particular
271-
field has, find the source code for the form field (and its parent fields)
272-
and look at the above two functions.
287+
object of your form when the Form component calls ``buildView`` and
288+
``finishView`` on each "node" of your form tree. To see what "view"
289+
variables a particular field has, find the source code for the form
290+
field (and its parent fields) and look at the above two functions.
273291

274292
.. note::
275293

276294
If you're rendering an entire form at once (or an entire embedded form),
277295
the ``variables`` argument will only be applied to the form itself and
278-
not its children. In other words, the following will **not** pass a "foo"
279-
class attribute to all of the child fields in the form:
296+
not its children. In other words, the following will **not** pass a
297+
"foo" class attribute to all of the child fields in the form:
280298

281299
.. code-block:: jinja
282300
@@ -292,10 +310,10 @@ The following variables are common to every field type. Certain field types
292310
may have even more variables and some variables here only really apply to
293311
certain types.
294312

295-
Assuming you have a ``form`` variable in your template, and you want to reference
296-
the variables on the ``name`` field, accessing the variables is done by using
297-
a public ``vars`` property on the :class:`Symfony\\Component\\Form\\FormView`
298-
object:
313+
Assuming you have a ``form`` variable in your template and you want to
314+
reference the variables on the ``name`` field, accessing the variables is
315+
done by using a public ``vars`` property on the
316+
:class:`Symfony\\Component\\Form\\FormView` object:
299317

300318
.. configuration-block::
301319

‎reference/forms/types/checkbox.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4,9 +4,9 @@
44
checkbox Field Type
55
===================
66

7-
Creates a single input checkbox. This should always be used for a field that
8-
has a boolean value: if the box is checked, the field will be set to true,
9-
if the box is unchecked, the value will be set to false.
7+
Creates a single input checkbox. This should always be used for a field
8+
that has a boolean value: if the box is checked, the field will be set to
9+
true, if the box is unchecked, the value will be set to false.
1010

1111
+-------------+------------------------------------------------------------------------+
1212
| Rendered as | ``input`` ``checkbox`` field |

‎reference/forms/types/choice.rst

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -109,15 +109,17 @@ The ``choice_list`` option must be an instance of the ``ChoiceListInterface``.
109109
For more advanced cases, a custom class that implements the interface
110110
can be created to supply the choices.
111111

112-
With this option you can also allow float values to be selected as data. For example:
113-
114-
.. code-block:: php
112+
With this option you can also allow float values to be selected as data.
113+
For example::
115114

116115
use Symfony\Component\Form\Extension\Core\ChoiceList\ChoiceList;
117116

118117
// ...
119118
$builder->add('status', 'choice', array(
120-
'choice_list' => new ChoiceList(array(1, 0.5, 0.1), array('Full', 'Half', 'Almost empty'))
119+
'choice_list' => new ChoiceList(
120+
array(1, 0.5, 0.1),
121+
array('Full', 'Half', 'Almost empty')
122+
)
121123
));
122124

123125
The ``status`` field created by the code above will be rendered as:
@@ -130,9 +132,9 @@ The ``status`` field created by the code above will be rendered as:
130132
<option value="2">Almost empty</option>
131133
</select>
132134

133-
But don't be confused! If ``Full`` is selected (value ``0`` in HTML), ``1`` will
134-
be returned in your form. If ``Almost empty`` is selected (value ``2`` in HTML),
135-
``0.1`` will be returned.
135+
But don't be confused! If ``Full`` is selected (value ``0`` in HTML), ``1``
136+
will be returned in your form. If ``Almost empty`` is selected (value ``2``
137+
in HTML), ``0.1`` will be returned.
136138

137139
.. include:: /reference/forms/types/options/empty_value.rst.inc
138140

‎reference/forms/types/integer.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -4,10 +4,10 @@
44
integer Field Type
55
==================
66

7-
Renders an input "number" field. Basically, this is a text field that's good
8-
at handling data that's in an integer form. The input ``number`` field looks
9-
like a text box, except that - if the user's browser supports HTML5 - it will
10-
have some extra front-end functionality.
7+
Renders an input "number" field. Basically, this is a text field that's
8+
good at handling data that's in an integer form. The input ``number`` field
9+
looks like a text box, except that - if the user's browser supports HTML5
10+
- it will have some extra front-end functionality.
1111

1212
This field has different options on how to handle input values that aren't
1313
integers. By default, all non-integer values (e.g. 6.78) will round down

0 commit comments

Comments
 (0)
0