This is an initial WIP. It is far from being finished, but the final goal is to completely describe Form Events in the component's documentation, and not only in the cookbook, which doesn't formally explains form events.

Wow, thank you!

Please note that there is already an article about form events in the cookbook:http://symfony.com/doc/current/cookbook/form/dynamic_form_modification.html You might be able to get some usefull things from it. At least, you should remove all things you put in the components article from that cookbook article and add a reference (or multiple references) to this new article.

In the end, we should have a components article telling you everything you need to know about Form Events and a cookbook article which gives you a short introduction and framework specific things. If you do not want to do this, someone of the community can do it after this one is merged. :)

Again, big thanks for getting this roling!

Done. Also added a bit of code for adding a form event listener and a form event subscriber when using the form builder.

👍 Great article! I really like it!

Rebased commits once again.

WOW, this is really incredible! Great great work!

I have one thought. There are basically 2 sections to this entry: (A) explaining the form lifecycle and different events and (B) how to actually register event listeners/subscribers. I think we should change their order: explain how to register listeners first, then explain the event second.

The reason is that I realized in the beginning (where we talk about the different events), we're talking about how to get at form data and the event object, as well as referring to events simply as SUBMIT, before really explaining that these are constants on FormEvents. If you reverse the order of these sections, I think it's an even better entry.

What do you guys think? After this issue (and I left one other small comment), this is ready to merge! Great work to everyone!

Hum, not sure. I just made the change locally, and it actually feels weird talking about form event listeners and subscribers before actually describing the events and the workflow. If we invert the sections, we need to rephrase a few things so it feels fluid.
In any case, I can also rephrase the sections of the documentation to refer toFormEvents::{EVENT_NAME} instead of simply{EVENT_NAME}.

Ok, let's keep it how it is - but yea, I likeFormEvents::{EVENT_NAME} better, and we can also add a quick note to the top with a link that points to the second section on usage. A very very quick example usage at the top of the chapter (not really doing anything, just showing the registration of an anonymous function on some form event, and the arguments of that callback) might be plenty to give people enough idea of how this works before explaining the events.

Thanks for checking it out :)

Done. And also rebased the commits.

Well then, I guess it should be ready for merge, now!
What do you think about it now,@weaverryan? :)

Updated

Fixed issue with travis build (underline too short)

ping@weaverryan

@csarrazi this PR is now ready. It'll be merged once@weaverryan has time to review and merge it. Since this PR add lots of stuff, it can take a little bit longer than smaller PRs. But don't worry, this great PR will never be missed by us :)

@csarrazi But you can remove the [WIP] tag from the title for now. So, it's more obvious that the PR is finished. :)

Thanks! I removed the [WIP] tag :)

bump@weaverryan ! :)

👍

Sorry for getting the merge slowly - this is a truly wonderful effort and entry. I'm looking forward to showing this resource to people who are working with form events. Great work to you Charles and everyone :). Thanks!