Rename field_attach_submit(), because it is also called from within validation

Yes, I noticed that when working on "widgets as plugins".
At some point during the EntityFormController work, field_attach_submit() calls got moved to EntityFormController::buildEntity(), which runs during validate.
Thus, I'm not sure what's the meaning of 'submit' anymore :-)

On this topic, also see #1768526: NodeFormController::validate() calls buildEntity() twice

Well, it used to mean "submit", but then the outside world changed the moment it called the function :-)

So it seems something like field_attach_build() would be a more accurate name. It does lack a bit of 'form' context though.
[edit: also, 'form build' is yet something else for FAPI...]

Suggestions welcome :-)

FWIW, the Symfony Forms component calls this bind(). So, I'm tentatively thinking field_attach_form_bind(). Without knowing Symfony's terminology, this is a little unintuitive though (at least for me). field_attach_form_bind_input(), field_attach_form_bind_values(), or field_attach_form_bind_submission() would all be more explicit, but then again, we don't add any of those suffixes for field_attach_form_validate() (though with validate, it's more clear, since what can you possibly validate other than the input/values/submission).

I kind of like "bind". But, true, it would be a little isolated on the drupal side. Unless there are other parts of the form flow that could be named accordingly ?

field_attach_submit() just maps the form values onto the entity object (see entity_form_submit_build_entity() and EntityFormController::buildEntity())

Note that there's a very important thing about buildEntity(), which is that it clones $form_state['entity'], and then calls field_attach_submit() and field_attach_form_validate() only on that clone. $form_state['entity'] is only updated during EntityFormController::submit(), which like any form submit handler, only runs if the form submission was valid. This way, invalid user input can never leak into $form_state['entity'].

if the EntityFormController notices there are zero validation errors, then it'll just save the entity object. No submit handler is involved at all. It took me a very long time to figure out this bizarre way of handling validation/saving.

EntityFormController::actions() creates a submit button and sets its #submit to its own 'submit' and 'save' methods. What's bizarre about that? It's two perfectly reasonable submit handlers, which like all submit handlers, only run if the form validated successfully.

What I do agree is bizarre though is that we name the function that copies $form element values to $entity field values (with the possibility of this not necessarily being a direct copy, but can include data transformation of some kind) "submit". Which is what this issue is trying to address.

What about field_attach_bind_form_values()? Since we're not binding straight user input/submission: FAPI has already done that prior to setting $element['#value']/$form_state['values']. Instead, we're doing a separate process of binding form values to entity field values.

Or, field_attach_bind_from_form()?

re #8:
Actually, 'extract_form_values' was an 'op' in D7 (field_default_extract_form_values(), was called in both field_attach_submit() and field_attach_validate().

So I guess, yes, reintroducing that extract_form_values denomination would be the way to go.
field_attach_submit() -> field_attach_extract_form_values()
WidgetInterface::submit() -> WidgetInterface::extractFormValues()

Or "bind" rather than "extract", but "extract" is what we have in D7, and "bind" isn't used anywhere else in core right now AFAIK.
I don't have a strong opinion here.

I'll submit a patch for the rename when "edit in place" is committed.
Better to avoid a reroll there...

OK, #1824500: In-place editing for Fields got in (kudos !).
Here's a patch.

Er, rather the non half-baked version, then.

Forgot that field_ui calls the method directly.

Rerolled after removal of $entity_type parameter.

#17: field_attach_submit-1846648-17.patch queued for re-testing.

#17: field_attach_submit-1846648-17.patch queued for re-testing.

RTBC+1. It's not a bug though, so recategorizing and retitling.

Trying to learn to be less verbose :)

This patch no longer seems to apply. Asking for a re-test.

#17: field_attach_submit-1846648-17.patch queued for re-testing.

Re-rolled, should be fine.

Committed/pushed to 8.x, thanks!

Will need a short change notice.

Thanks !
Change notice created at http://drupal.org/node/1907724.

untagging

Also added a note in http://drupal.org/node/1882428