[Form] Allow Form events to be used as expected with inherit_data option

[cristoforocervino]

Q	A
Branch?	7.1
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	#8607, #8834
License	MIT
Doc PR	TODO

This PR allows PRE_SET_DATA, POST_SET_DATA and SUBMIT form events to be used also with inherit_data option set to true.
On top of that, usage of PRE_SUBMIT and POST_SUBMIT was allowed with inherit_data option but dispatched events have $event->getData() as null. This PR addresses that issue as well.

Even if the documentation explains (at the very bottom of this page) that those form events are not going to work when the option inherit_data is used, I think it's a common problem you could run into with an advanced use of Form component (also because no exception is thrown when you use *_SET_DATA, SUBMIT and inherit_data together).

This is important to keep the high consistency standard Form component has.
Without this PR, the form component behaviour is ambiguous but known and documented, so I think we should consider this a new feature instead of a bug fix.

[xabbuh]

I am a bit worried that merging this would break existing applications that rely on the fact that their listeners are not called on forms that have the inherit_data option enabled.

[cristoforocervino]

Should this behavior enabled with an option?
I don't know, this is probably a BC Symfony 6.x could have but I see no reason to wait until then.
I'm open to suggestions to change this feature in order to make it safer for existing applications.

[xabbuh]

Do you have a concrete use case in mind where removing this limitation would be useful?

[cristoforocervino]

Using PRE_SET_DATA event is the only way to add a form child and change its options based on given object state.

Let's suppose we have a form child we want to render as disabled false when creating a new entity (letting the user to set its value) and render it as disable true while editing (because the value cannot be changed but has to be shown).

There is no way to achieve that without PRE_SET_DATA on forms with inherit_data option.
The above is the actual use case that made me discover this Symfony Form limitation.

[Amunak]

Any chance of moving this forward? It seems extremely counter-intuitive that some FormEvents are called on child forms and others aren't.

[stof]

Any event allowing to modify the data is actually incompatible with inherit_data by design. So I'm not sure we should pursue this.

[stof]

This would not allow child forms with inherit_data to change the model data of the parent form. This is a very bad idea IMO (and was one of the reasons why this was not supported)

[stof]

This is broken. It will replace the whole submitted data by the data of the child only.

[Amunak]

Any event allowing to modify the data is actually incompatible with inherit_data by design. So I'm not sure we should pursue this.

Why do you consider them incompatible? If this is by design it should be documented that some events trigger every time and others don't.

[stof]

@Amunak see my comments on those lines that describe the problems.

[cristoforocervino]

@stof I understand. But if this is incompatible by design, wouldn't be better to throw an exception when you use *_SET_DATA, SUBMIT and inherit_data together?