Spin-off from #1499596-96: Introduce a basic entity form controller:

I also tried to remove customly invoking form-main-level validation handlers, but that seems to be necessary. I guess we should move the a validation-hook here, but let's leave it to a follow-up to introduce all kind of hooks. (altering?, entity-building, validating, submitting)

To be completed.

Comments

I'd especially love it if other modules could rely in their form submission handlers on the fact that the primary entity's form submission handlers were already invoked.

E.g., in the Mollom module, I'm facing the situation that I need to store data that relates to the entity in my form submit handler. However, it is not always guaranteed that the primary entity form's submit handler has run already — especially when button-level submit handlers are involved, such as node_form_submit_build_node() of the node form's "Save" button.

As a developer integrating with an entity form, I'd ideally like to have pre-entity-submit and post-entity-submit hooks. I created an issue for that some time ago already:
#1150756: Improve integration with entity form button-level and form-level submit handlers, form/entity (re-)building, and previews

This seems to be closely related, so I wanted to mention it here.

In the initial iterations of the entity forms patch I introduced something along those lines in the form of entity prebuilders, callbacks invoked before entity building. In the current form the the controller tries its best to ensure that entity building is properly done before any other submission handler kicks in. However since the form is alterable we cannot guarantee that in anyway. OTOH if someone explictly sets a submit handler before the controller one in theory she should be aware of what she's doing.

That said, I agree that introducing dedicated hooks and recommending people to use them instead of directly injecting custom handlers, would be the best way to ensure that the entity submission workflow is not messed up.