Spin-off from #1499596: Introduce a basic entity form controller: we need to be able to reuse the form generated by an entity form controller and ensure it can be embedded into another form.
To be completed.
and we need to make sure that we can embed multiple forms at the same time!
This partially duplicates a couple of other issues:
#367006: [meta] Field attach API integration for entity forms is ungrokable#766146: Support multiple forms with same $form_id on the same page
I'm interpreting this issue as wanting to put the $form returned by EntityFormControllerInterface::build() into some other $form such that the HTML output is a single <form> tag. Is that correct, or is this about wanting multiple $form arrays sharing the same $form_id (e.g., several entities of the same type) to be each rendered as their own <form> tags, but to not have id / form processing collisions when all rendered on the same page?
fwiw, I'm interpreting this as meaning that I could put any (or many) entity forms into the same form and determine what sort of entity forms existed within this and hand off processing of that separately. Something like:
<?php$form = array();$node = entity_create('node', array( 'uid' => $user->uid, 'type' => 'page', 'langcode' => node_type_get_default_langcode('page'), ));$form['node'] = entity_get_form($node);$form['something_else'] = array( '#type' => 'select', '#options' => ...);?>
And then be able to iteratively pass the form state to entity_form_submit and have it process the various entity forms embedded in the greater form. Is this a correct interpretation?
I think @fago's plan is to support both scenarios in #3.
Is this correct?
I think your example is not correct because entity_get_form() returns an already processed form ready to be rendered. As pointed out in #3 the correct way should be using the value returned by EntityFormControllerInterface::build().
I was thinking of what is described in #4. Avoinding form id collisions is something different we might want to fix generally elsewhere.
Suppose menu_overview_form is nice example of 2 forms
I missed that issue so far, interesting, it's precisely the kind of things I'm about to bump into in #1992138: Helper issue for "field types as TypedData Plugins".
Late in the D7 cycle, we had quite some work to make sure Field API form integration (include widgets, extract values, validate and assign errors back to form elements) works with forms containing several entities. field_test_entity_nested_form() is a simple example in core right now, and IIRC, field_collection relies on this mechanism.
Not sure how this can play with EntityFormControllers that include more and more entity logic. #1992138: Helper issue for "field types as TypedData Plugins", among other things, removes field_attach_form_validate(), and moves the equivalent code in the EFC - and right now I'm not sure how to make the tests around field_test_entity_nested_form() pass again.
See #2006248: Add an EmbeddableFormInterface so that FormInterface can delegate to multiple objects for a generic solution.
Given entity forms need to replace field_attach_form() we need to fix this for entity forms being a full replacement.
Discussion in #2090509: Optimize entity_get_render_display() for the case of "multiple entity view" derived on "Edit in place"'s EditFieldForm, and from here "inline entity form" - see #2090509-28: Optimize entity_get_render_display() for the case of "multiple entity view".
The current situation is :
- Base fields can now be rendered by widgets.
- The ones that aren't are rendered through custom code (either in EntityFormController:buildForm() or in form alters) that is only triggered by "the official entity form with the right form controller and form_id"
- It's difficult to abstract those out and decide whether they should also be applied to an inlined form or a "single field" form.
Wouldn't it just be good enough to provide easy support for "include field widgets for an entity in your custom form/subform" (with validation and extraction of values) ? - i.e simply our current field_attach_form*() refreshed for OO ?
Does "inline entity form" do anything else than rendering the field widgets right now ?
#2095195: Remove deprecated field_attach_form_*() has an initial patch with those "generic widget attachers". The question is: where do we put them...
Drupal is a registered trademark of Dries Buytaert.