this is wrong IMO as your transformation would not apply changes done by listeners (and so is incomplete). The issue with your approch in #3514 is that you are mixing the different representations of the data, as you expect your listener to use the app data whereas it works at the level of norm data or client data.

Hmm... You're right about the listeners. I added them to the method.

I'm still convinced that in some (many) cases the app data (of children) is necessary in the bind_client_data event. Two examples are shown in the beforementioned PR.

In the previous PR you stated that I was probably using the wrong event, yet BindClientData is the only event to use. For example, I have a form with a country field and a state field. Someone changes the country from Netherlands (no states) to USA (has states). The state field is actually added and the user submits some data. Then the form gets submitted and bound a second time. Since the original data still had the country NL, a state field is only added from the listener. If I'd do this in the BindNormData event, I'd have the correct Country entity available together with its getStates() method, but since a state field was not yet created, the client data can and will never be mapped and therefor gets lost. If I'd do it in the BindClientData event, all I'd have is a country ID and no way to fetch its states, so I'm not able to generate the state field with its correct choice list.

As stated before, I'd either have to fetch the country from the EM which I'd also have to inject into the form to be able to inject it into the listener, or use the forms Transformers, which already have the necessary services injected...

Come to think of it, now it's still not correct, of course, as there is a lot of logic missing between clientToNorm and normToApp...

I did some updates. Perhaps this is better? Although some checks need to be made to check whether the key is set in the clientData array

Data transformation and fired events should only occur during binding and prepopulation (setData). We need a new mechanism here that works in scope of the bind() method. I created a new issue (linked above) that summarizes the essence of this PR in a feature request.