Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[Form] Introduce validation events for forms #37641
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] Introduce validation events for forms #37641
Changes from all commits
9112ef8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just asking, why not
?
same for
PreValidateEvent
andPreValidationEvent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've got a point. I'm not entirely convinced by "validate" either, but I'm open for ideas. Any opinions or objections to the suggested wording?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first i see the listener is called validationListener, thus suggest using validationEvent
but then, i saw the method is called validateForm, so maybe the word validate is ok
(i have in mind the workflow event logic, where event are named after the method) :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be the following?
$this->eventDispatcher
is never set at this point.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any reason for these events to be root-only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Validation is only triggered for root forms, hence the checks here. The validator then traverses the form and its data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given i have a custom form type listening to VALIDATE events
now, im nesting this form type somewhere else ...all of a sudden the listener isnt called anymore on the child type.
Im not sure that's expected, given validator service maps violations back to underlying form types, so each type has a PRE/POST validation knowledge imho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the issue is that this is form validation. Form validation is only triggered on root forms. You always have to attach validation listeners to the form that is being validated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
form validation bubbles down.
put different, why shouldnt i be able to listen to POST_VALIDATE in a child form to check for some synchronized errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Form validation does not bubble down. Validation does, in that the form validation metadata contains a
Traverse
constraint, which triggers validation for fields, child forms, and the entity. The POST_SUBMIT event for any non-root forms does not trigger validation, which is why there should be no form.(pre|post)_validate eventThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm yes, i agree. Im a bit worried the difference is too subtle, compared to current post-submit with prio >0.
Is there any reason to prefer the new events actually? other then cosmetics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am kind of interested in this discussion - because my Bundle does exactly this. It works quite nicely.
The most important parts for me - and my project - were - it has to bubble down - because I want to be able to run code inside of child forms whenever the whole form was successfully validated.
And inside of the $event variable, you have to be able to access the current form (current child) and the root form. Otherwise, it would not be possible to detect what data to use for some action like uploading an image or persisting an entity etc.
Like I said. My bundle works like a charm. I like to see this inside the Symfony core (form component).
But if these success metrics are not given, I will stick to my bundle ;).
Anyways. I like to see that you guys put effort into this.