New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Form][DelegatingValidator] errors related to input[type=radio] rendered in wrong place #1917
Comments
I'm having the same problem. The issue lies in the DelegatingValidator class: foreach ($violations as $violation) {
$propertyPath = $violation->getPropertyPath();
$template = $violation->getMessageTemplate();
$parameters = $violation->getMessageParameters();
$error = new FormError($template, $parameters);
foreach ($mapping as $mappedPath => $child) {
if (preg_match($mappedPath, $propertyPath)) {
$child->addError($error);
continue 2;
}
}
$form->addError($error);
} The mapping never matches the radio or select id and therefore the error is appended to the form |
Situation example: I have one form called "user", with a subform called "profile". Fields in subform that aren't expanded choices have mappings like "[/^children[profile].data.name_of_field(?!\w)]" The target property_path of the constraint violation for these fields is "children[profile].data.name_of_field" This way, preg_match($mappedPath, $propertyPath) for expanded fields will not match |
I'm not able to reproduce this issue. Furthermore, when using radio buttons, I don't see what kind of errors you can have (except if you mess up with the HTML source code of course)? Anyway, can you provide a simple example that exhibits the problem? Thanks. |
I'll try to build up an example in these days and I'll submit as soon as possible... |
@fabpot I'm having a similar issue, although not with radio buttons but with an integer field. The constraint:
The (partial) form:
When I change the form field type to Should I open a new issue for this? |
@pkruithof: yes please. |
We're having similar issues with EntityType fields. When the underlying entity selected isn't valid the errors generated are attached to the root form object (and then usually don't have any meaning). It would be good if 'choice' fields similar had an option not to validate the selected entity. I think there is a case for making this validation optional. There are scenarios with legacy data (or even just changing requirements) where you are willing to have "invalid" data in the system, but want to make sure that next time it's update it is made valid by the user. |
I'm also experiencing the same problem. Here's how my form is structured:
Validation errors for that choice field get attached not to the field or to it's enclosing form, but to the top. It seems like the changes made by @tamirvs resolve it. |
@spantaleev does it still occur in the master branch with the refactoring ? |
Strange.. I couldn't reproduce this on 2.0.12, 2.0.12 + the Form component from master, and the 2.0.10 that the project was using at the time. I don't have the exact piece of code that created that form structure before, so I had to recreate it again now. Maybe I had something slightly different then, or something else changed.. In any case, things seem to be fine for me now. |
@stof I was able to reproduce this error on 2.0.12.
In this case, I was able to fix it Here, please have a look :) |
This is still an issue, please don't close it if it hasn't been fixed yet... |
@webspin please try with Symfony master as many things changed in the Form component (and some changes have been made for the mapping of errors) |
I just came across this error (expanded embedded forms) with 2.0.15 and the changes @webspin posted did fix it. Be good if we could get this fixed in the 2.0 branch as it can leave some pretty nasty bugs |
@stof the changes linked to here: tamirvs@cd136d0 |
So, is this fix coming or do I really need to upgrade to 2.1? (which sucks, being the ***** kohana style of doing stuff) |
When using expanded choice list (input[type=radio] tags), error is bubbling in top of the form and not next to the errornous field, when expanded is set to false (select tag), everything workds as expected...
The text was updated successfully, but these errors were encountered: