Skip to content

[Form] [Validator] Errors bubble on underscored field names #11388

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.

Sign up for GitHub

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

Jump to bottom
Closed
redstar504 opened this issue Jul 14, 2014 · 3 comments
Closed

[Form] [Validator] Errors bubble on underscored field names #11388

redstar504 opened this issue Jul 14, 2014 · 3 comments

Comments

@redstar504
Copy link
Contributor

I believe I have found a bug in the Form or Validator component.

If you have a data_class that uses the camel case naming strategy for it's properties, and in your FormType you use underscores for the field names, the data gets mapped between the form and the object properly, but the errors for the underscored fields get bubbled to the parent form.

For instance, say you have a FormType with a data_class of Company. The Company class has a property named numberOfEmployees. In a FormType for this class, you can call your field number_of_employees, and the data currently gets mapped between the Form and the Company class properly. But say you have a constraint on the Company::$numberOfEmployees property, the resulting error for the number_of_employees field will appear on the parent form, and not on the field itself.

This doesn't occur if you use camelcase for the FormType field names, but this isn't always desired, as many times the HTML convention is to use underscores for field names and identifiers.

I was able to reproduce this issue for the latest Symfony and will begin working on a patch if someone can confirm this is a bug. Let me know if I need to clarify anything or if this is a duplicate as well.
@tompedals
Copy link

This may not be anything to do with the property names. There is a bug in the Validator component that causes errors to be mapped to the wrong place when using the 2.4 validation API.

Try selecting the 2.5-bc validation API in your config (see the 2.5-UPGRADE file for details).

@redstar504
Copy link
Contributor Author

@tompedals It still bubbles that field error when using the 2.5-bc validation API. When I try to use 2.5 I get:

Catchable Fatal Error: Argument 1 passed to Symfony\Component\Form\Extension\Validator\Type\FormTypeValidatorExtension::__construct() must be an instance of Symfony\Component\Validator\ValidatorInterface, instance of Symfony\Component\Validator\Validator\RecursiveValidator given, called in /home/redstar/proj/symfony-standard/app/cache/dev/appDevDebugProjectContainer.php on line 1295 and defined in /home/redstar/proj/symfony-standard/vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Validator/Type/FormTypeValidatorExtension.php line 36

@stof
Copy link
Member

stof commented Jul 15, 2014

Well, if you use underscores in the form and camelCase in the object, this is expected that the property path does not match. fooBar and foo_bar are different property paths, even though the standard accessors for both will be the same (which is why the form binding works even though the names don't match). This is why the the error will not be mapped in the right place.

If you still want to use underscores in the names, there are 2 solutions:

  • use the property_path option to set a property path to something different than the form name (using the real property path in your object graph).
  • use the error_mapping option to map errors from the camelCased property path to the underscored one

@tompedals the 2.4 API bug has nothing to do in this case.

For the error you get when using the 2.5 API, it will be fixed by #11350

@stof stof closed this as completed Jul 15, 2014
@spydemon spydemon mentioned this issue May 10, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@stof @redstar504 @tompedals