To the folks more familiar with the event dispatcher than me, please let me know if creating event names is still appropriate, or if the Pre|PostValidateEvent event classes are all the system needs to know.

As others have suggested on Slack, the fact that pre/post validation events are triggered during post_submit seems weird. However, any changes to this logic would already constitute a BC break:

• Registering a post_submit handler with priority < 0 makes it a pre_validate event
• Validation happens as a post_submit handler with priority = 0
• Registering a post_submit handler with priority > 0 makes it a post_validate event

Triggering validation in a separate step either before or after post_submit makes it impossible for users to rely on validation being done/not being done when their listener is invoked. Thus, we now give people two additional events to listen to validation without needing to know when during the submit step it is done. If you have other suggestions on how to avoid BC breaks, please let me know.

we could migrate all current post-submit listeners with prio >0 to post_validate, along with a deprecation it should be configured as such.

then in 6.0 post-submit comes free, and as of then it's equivalent to pre_validate instead. Which raises the question if we really need pre-validate.

@xabbuh Do you time to review this PR?

Gentlemen,

I'd like to discuss another use case for these events -- a use case that is not catered for by this PR, while I think it should be. I'm happy to move it to a new feature request ticket if necessary, however I believe it's best discussed in the context of this PR to avoid potential "change on a recent change".

I second what @ro0NL said in his review here: https://github.com/symfony/symfony/pull/37641/files#r460019018. In other words, the POST_VALIDATE has to be dispatched on all children forms recursively, to be useful and not to introduce confusion that @ro0NL mentioned.

I realise that the validation is triggered on the root form only (which then recursively validates the entire form tree -- this is done for a very good reason), however that's not a reason for not dispatching the events on the entire form tree.

To reiterate what @ro0NL said: given 2 FormTypes: FooType and FooChildType, where FooChildType is one of the child fields on FooType, developers should be able to listen on FormEvent::PRE_VALIDATE and FormEvent::POST_VALIDATE on both of these FormTypes and expect that these events are called on the deepest FormType-first (i.e. FooChildType first and then FooType second) at appropriate times, so that:

1. Developers can store extra bespoke routines/validation relevant to a given FormType in that FormType.
2. Developers may run extra bespoke routines/validation on a FormType irrespectively of whether that FormType is being submitted as a root form or not. Example: 2 api REST POST endpoints for a /blog-post and /blog-post/comments. The first endpoint would be submitting a BlogPostType as a root form (with BlogPostCommentType as a child field), and the second endpoint would be submitting a BlogPostCommentType as a root form.

Currently, there's no way to achieve the above (without creating new Constraints/ConstraintValidators) because form validation is initiated only on the root form (again, for a good reason).

What I propose is that instead of doing the following:

// ValidationListener.php

public function validateForm(FormEvent $event)
{
    $form = $event->getForm();

    if ($form->isRoot()) {
        /* ... */

        if ($this->eventDispatcher) {
            $this->eventDispatcher->dispatch(new PostValidateEvent($event->getForm(), $event->getData()), FormValidationEvents::POST_VALIDATE);
        }
    }
}

the following is done:

// ValidationListener.php

public function validateForm(FormEvent $event)
{
    $form = $event->getForm();

    if ($form->isRoot()) {
        /* ... */

        /*
         * Proof-of-concept code. I didn't run and test it. Just trying to get my point across.
         */
        $recursiveFormIterator = new RecursiveIteratorIterator($form, RecursiveIteratorIterator::CHILD_FIRST);
        foreach ($recursiveFormIterator as $iteratedForm) {
            $iteratedForm->getConfig()->getEventDispatcher()->dispatch(new PostValidateEvent($event->getForm(), $event->getData());
        }
    }
}

Benefits of the solution above over the one in the current PR:

1. No deprecation: event dispatchers are accessed on the iterated form instances.
2. No confusion: the new form events are run on all forms in the tree. Easier to explain in the Symfony docs, once merged.
3. The new class FormValidationEvents is redundant. Instead, then new events should sit in the already existing FormEvents class.
4. No reliance that the ValidatorListener class is using the exact same instance of EventDispatcher as the root Form being validated. I personally find this reliance very dodgy and implementation-dependent.

@alcaeus, please let me know what you think of it when you have time. The solution does solve your use case as well.

Thank you.

this will make it even more confusing when explaining the order of post_submit < 0, post_submit > 0 and pre/post_validate, as the order will be different for the root form and for child forms in your proposal...

I agree, stof. In my opinion it is a necessary evil and a natural consequence of the fact that validation is initiated from the root form only. Plus, it is already confusing when a dev discovers that their child form is still not validated when they're attempting to do additional things in a post_submit event (with priority less than 0). I had a solid wtf-moment when I discovered it and I'm sure any dev that attempted to do anything more involved with Symfony Forms can relate to this. By introducing the pre/post-validate events, the framework explicitly says "here's how the things are, stick to these rules and you'll be just fine".

To me it's a matter of including proper explanation in the docs that the order of events in the root form is different than in children forms (root: pre-validate, post-submit (at priority 0), post-validate; children: post-submit (at any priority), pre-validate, post-validate), rather than binning the entire feature because it has rough edges.

Additionally, I'd say that devs will be more likely to use the post-validate event alone, once it introduced, rather than the post-submit because I personally can't think of any other use case a dev might have to do in a post-submit-like event other than "I want to run this additional, complex checks after individual fields have been validated by the framework".

Please re-consider.

@alcaeus @stof What's the next step?

We've just moved away from master as the main branch to use 5.x instead. Unfortunately, I cannot reopen the PR and change the target branch to 5.x. Can you open a new PR referencing this one to not loose the discussion? Thank you for your understanding and for your help.

Thanks @fabpot! I've recreated this as #38214

@ro0NL and @d-ph, please raise your questions again in the new PR if they persist so we can continue discussing this PR in one spot.

What's the next step?

The new PR is missing a review from maintainers, but good to go otherwise. If the Symfony Team is open to including these events, I'll update the new PR with the rest of the required changes (changelog, deprecations, documentation)