related with this add
see pull 9581
#9581

Why are #9581 and this one separate PRs? They belong together in one.

@Tobion yes

@Tobion they are separate, because @Belgacem-TLILI used the online editing from the symfony repo, which created 2 separate branches (one for each edition done on the repo where he has no write access).

@Belgacem-TLILI you should do all the work in a single branch

And I don't think this is necessary. The FormError is associated to a single Form instance. Putting the violation property path does not make sense IMO. The mapping is already done between the validator property path and the right form.
If you want to know which field has the error, don't make the errors bubble up to the root form. In 2.4, getErrors() will return a recursive iterator, allowing to access all form errors including the child ones (and knowing where they are attached).
If your goal is to send the validation errors for your ajax requests, a solution for now is to use JMSSerializerBundle, which is able to serialize the errors for a whole form (or do your own function iterating over the form to get all errors in case you don't like the JMSSerializer format)

@stof i have no the some idea,
if i like to return an array using getErrors function, with this update i'll get for exemple
array('field1'=>'error message field1'),
the getErrors actually function return list errors message without index

this add give user possibility to use the some existing function (getErrors) to render fields name without installing any other bundle or any personal function

@Belgacem-TLILI getErrors in 2.3 and below returns an array of errors attached to a given Form in the tree. It does not return errors from children.
In 2.4, the return value has been changed to an iterator. Iterating over it normally produces the same output than in 2.3: you get the errors for this Form only. But iterating it recursively (with RecursiveIteratorIterator) will allow getting errors from children too.

And if you are using error_bubbling in your form to move all errors on the root form, errors are no longer attached to a child form in the tree. thus, ginving the property path of the violation in your object graph may not help the client code. The object graph does not need to match the form tree (you have a property_path option in the form to use a different property path than the default value inferred from the name)

and even if the FormError contains the property path, you will still need a personal function to build the data in the format expected by your AJAX response. The only difference if your PR is merged is the logic you will put in it

this is very useful and interesting
it recovers the field names with the error message associated

actually I like this one. It'll fix #9472

this add will use existing function, there is no new class, no new functions, no installing new bundles
it's great to just add some line to get very useful function

would be better if you write tests or a use case even as a description and with code

hello
does this pull will be merged on next version or not ?

please use the standard table format for PR found in the docu

@bschussek please could you take a look at this? @Belgacem-TLILI definitely this will not be merged, if it gets merged, as it is. As @stof and others have said please work this out in a single branch and create a new PR or push -f this one.

Replaced by #9993.