Fix the definition of customizing form's global errors. #3543

mtrojanowski · 2014-02-05T15:51:21Z

The documentation for customizing global errors was actually still referring to the way it was done in 2.0. (where two different blocks were used: field_errors and form_errors). Since 2.1. only form_errors is used and errors are differentiated using the compound variable (set to true for form errors).

Q	A
Doc fix?	yes
New docs?	no
Applies to	2.3+
Fixed tickets	#3542

mtrojanowski · 2014-02-05T15:52:14Z

cookbook/form/form_customization.rst

-as above, but now call the block ``form_errors`` (Twig) / the file ``form_errors.html.php``
-(PHP). Now, when errors for the ``form`` type are rendered, your customized
-fragment will be used instead of the default ``form_errors``.
+as above, but now check if the ``compound`` attribute is set to ``true``:


I'm not sure which is more correct for the compound - attribute or varaible.

I'd add also an example block as in #3542. This way it's easier for new comers understand what to do without searching for something that simply does not exist. Wdyt?

I'm not sure if I understand you correctly. There is an example block below this line. Do you think that anything else should be added?

AH! Shame on me :) Just replied to your comment and didn't see the rest. Well looks good to me!

I'd use "variable" - consistent with our conversation on "form variables" elsewhere.

Also, how about a small sentence about compound? Something like:

If the ``compound`` variable is ``true``, it means that what's being rendered is a collection of fields (e.g. a whole form), and not just an individual field.

Feel free to work on the wording - that's tough to get clear :).

mtrojanowski · 2014-02-05T16:04:27Z

While inspecting this issue I started to wander if this fragment is adequate (same file, line 773):

  You can also customize the error output for just one specific field type.
  For example, certain errors that are more global to your form (i.e. not specific
  to just one field) are rendered separately, usually at the top of your form:

The first sentence suggests that you can customize the errors for each field type separately, but I don't think this is the case. Can anyone confirm if it's possible or is the sentence a bit misleading?

stof · 2014-02-05T16:40:28Z

@mtrojanowski you can. It works exactly the same way than customizing the widget of a field (except that the block name ends with _errors instead of _widget)

mtrojanowski · 2014-02-05T18:23:10Z

@stof thanks. It's good to know. Maybe it's worth mentioning it in the docs implicitly. Now I think it's a bit to vague. I'll think of something and add to the PR.

mtrojanowski · 2014-02-05T22:40:20Z

Added the note on how to customize errors for different field types. In fact I found this information in a sidebar a few sections above ("Knowing which block to customize"). Nevertheless I think it's better that all the information about the error customization is in one place (even if some of the information is doubled in the article).

weaverryan · 2014-02-11T18:10:33Z

cookbook/form/form_customization.rst

+                                <li>{{ error.message }}</li>
+                            {% endfor %}
+                        </ul>
+                    {% endif %}


What about the else? We're not trying to customize the else case here, but of course without it, non-compound errors won't show up - so we'll need something :)

btw, @mtrojanowski happy to see you around here lately :)

the example code to contain `else` statements.

mtrojanowski · 2014-02-20T21:12:56Z

Took me a while but finally fixed the code according to the comments :)

mtrojanowski · 2014-02-20T21:14:34Z

cookbook/form/form_customization.rst

-fragment will be used instead of the default ``form_errors``.
+as above, but now check if the ``compound`` variable is set to ``true``. 
+
+.. tip::


I added the part about the compound var as a tip. Or would you rather leave it as a regular sentence in the text?
@weaverryan @wouterj

I would put it in a regular sentence

mtrojanowski · 2014-03-16T17:40:54Z

Applied the changes proposed by Wouter. As for the colons and semicolons in PHP templates I understand that I don't have to change anything there, right?

weaverryan · 2014-03-18T12:54:15Z

Woot, thanks Michał! :)

…rojanowski) This PR was merged into the 2.3 branch. Discussion ---------- Fix the definition of customizing form's global errors. The documentation for customizing global errors was actually still referring to the way it was done in 2.0. (where two different blocks were used: `field_errors` and `form_errors`). Since 2.1. only `form_errors` is used and errors are differentiated using the `compound` variable (set to `true` for form errors). | Q | A | ------------- | --- | Doc fix? | yes | New docs? | no | Applies to | 2.3+ | Fixed tickets | #3542 Commits ------- 6f6fcca Applied some changes according to comments. e3b20d8 Minor rewording. Added tip about meaning of `compound` var and expanded the example code to contain `else` statements. 1e278c4 Added note about customizing errors for different field types. 236d06b Fix the definition of customizing form's global errors.

mtrojanowski · 2014-03-18T13:06:38Z

Always a pleasure :)

mtrojanowski reviewed Feb 5, 2014
View reviewed changes

weaverryan reviewed Feb 11, 2014
View reviewed changes

mtrojanowski added 3 commits February 20, 2014 22:09

Fix the definition of customizing form's global errors.

236d06b

Added note about customizing errors for different field types.

1e278c4

Minor rewording. Added tip about meaning of compound var and expanded

e3b20d8

the example code to contain `else` statements.

mtrojanowski reviewed Feb 20, 2014
View reviewed changes

Applied some changes according to comments.

6f6fcca

weaverryan merged commit 6f6fcca into symfony:2.3 Mar 18, 2014

Uh oh!

Fix the definition of customizing form's global errors. #3543

Fix the definition of customizing form's global errors. #3543

Uh oh!

Conversation

mtrojanowski commented Feb 5, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrojanowski commented Feb 5, 2014

Uh oh!

stof commented Feb 5, 2014

Uh oh!

mtrojanowski commented Feb 5, 2014

Uh oh!

mtrojanowski commented Feb 5, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrojanowski commented Feb 20, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrojanowski commented Mar 16, 2014

Uh oh!

weaverryan commented Mar 18, 2014

Uh oh!

mtrojanowski commented Mar 18, 2014

Uh oh!

Uh oh!