Needs to check the php version of the configuration.

Hi Sebastien!

Cool, a whole new entry! :) First thing though, how do you see this as different/similar tohttp://symfony.com/doc/current/cookbook/form/dynamic_form_generation.html?

If it's not different, should we combine the entries? Was the existing article not easy enough to find (<-- this is very possible). Also, the existing entry uses a subscriber (i.e. a whole other class for the listener), whereas your entry uses an anonymous function. I wouldmuch rather show the user how to do this using an anonymous function, and then just mention that this logic could also be in its own class. So, at the very least, that's one piece of your entry that I think we definitely need to integrate.

Let me know what you think and we'll go from there! I think this is a very important topic, so I would like to get this done well.

Thanks!

I have merged the two articles.

I have added another section for some more advanced use of the form events and dynamic generation. In that last case, using closures wouldn't make sense. So I think it's good to keep both on the cookbook entry so users know what are the different options.

Hey Sebastien!

This is a very complete example :). But I have a few questions first!

1. I still think we have some repetition between the original part of this entry and your part. The first part talks about using posted data to dynamically change the form. You talk about this as well - and also show using auserId instead of the submitted data. I think we need to merge the two examples - there should probably only be one example using thePRE_SET_DATA in this way.

2. There are some whitespace differences as well in the file - probably due to line break differences.

3. Merging the 2 parts of this entry may solve it, but we may have too many other details. For example, showing the user how to register a form as a service and use it in the controller should be here. The goal is to be as "dense" with new information as possible (while still making it a full "story"). The less other details, the more we can get the "meat" of this entry across to the user. Nobody actually likes reading - so shorter = better ;)

Thanks!

ping@khepin

Yikes, been a while!
I removed the parts of the article that duplicate something that is explained elsewhere.

I kept all the examples as I feel they fit different use cases and sticking all of them together would create confusion.

Let me know what you think.

Hey Sebastien!

Thanks for the updates on this, I've finally just merged it into the 2.1 branch. I'll have another PR coming shortly with some tweaks as I wanted to re-read this big chapter anyways.

Thanks!