Problem/Motivation
In #1875992: Add EntityFormDisplay objects for entity forms we introduced the foundation for form modes but without any actual usage in core. This is the necessary followup :)
Form modes are the equivalent of view modes, applied to entity forms. They were whispered around the corners in various issues for quite a while (e.g. #1668292-17: Move simplified Profile2 module into core), greated with much enthusiasm at the end of the Field API session from DrupalCon Portland and, imo, mandatory if we want to fix things like #1911080: Replace menu node form additions with entity reference field in a truly generic way. They are also *very* useful for dead-simple creation of multistep entity forms (wizards in ctools speak).
Thanks to the recently added hidden widget and entity form displays, this functionality is achieved by removing code from core .. *gasp* :D In a nutshell, the patch removes half of field_ui.js, 30-40% of field_ui/FieldOverview.php, field_ui/Form/FieldWidgetTypeForm.php entirely, and refactors field_ui/DisplayOverview.php and a couple of other pieces to work generically for both widgets and formatters.
Who will benefit from this
- Kill the checkbox workaround in Field API to show fields on user register form
- Menu entity form embedded in nodes
- Multi step form
- Inline entity form
- DS/FieldGroups - whoever, because we now have a unified UI (technically) for moving rows around, changing formatters etc.
User interface changes
- a new 'Manage form display' tab appears in all Field UI screens, between 'Manage fields' and 'Manage display'
- the drag-n-drop functionality from 'Manage fields' dissapears
-
widgets will be handled (like field formatters) in only one screen: 'Manage form display'. Previously they were scattered in three places:
- they were originally selected in 'Manage fields' when you create a new field
- their settings were handled in the instance edit form
- they could be changed in a separate form, presented as a subtab of the instance edit form
API changes
- a new 'form_mode' config entity is introduced, handled exactly like the 'view_mode' one introduced in #1043198: Convert view modes to ConfigEntity
- the hacky 'user_register_form' setting dissapears from all field instances
Open questions
- should we keep displaying 'extra fields' in the 'Manage fields' tab?
- related to the one above, should we convert the 'Manage fields' tab to a EntityListController (in this patch or a followup, probably #1963340: Change field UI so that adding a field is a separate task)?
- should the 'default value' handling in the instance edit form only use the default widget of a field?
- what sorting criteria to use in the 'Manage display' fields? right now the order is alphabetical
Followups
Nothing critical or major, of course.
- this patch already does a lot of cleaning up in DisplayOverview(Base)::buildForm(), but we can still use #1854880: Cleanup DisplayOverview::form if we want to do more
Remaining tasks
- implement the new settingsSummary() method for all existing widgets
- create the equivalents of hook_field_formatter_settings_form_alter() and hook_field_formatter_settings_summary_alter() (right now they are still called in the base class, therefore executed for both formatters and widgets)
- upgrade path
Another debatable/sensitive part is the $operation argument of entity_get_form(), which currently maps to entity form controllers. In the initial patch I've let them coexist in peace, giving us following options. Using 'step_1' as an example form controller/operation AND the same 'step_1' form mode:
- if both the form controller and form mode exist, the entity form will use the 'step_1' form controller and display only the fields configured in the 'step_1' form mode
- if the form controller exists but the form mode does not, the entity form will use the 'step_1' form controller and display the fields configured in the 'default' form mode
- if the form controller does not exist but the form mode does, the entity form will use the 'default' form controller and the fields configured in the 'step_1' form mode
Now, given that #1839516: Various subsystems require an Entity Operations API. Introduce one. has seen some movement lately and it's likely to get into D8, I think it makes sense to just rename the current entity 'operation/form controller api' to a 'form mode api'. This way, we will still have the three cases from above, but the concept will be much simpler: Entity forms use form modes in order to determine what fields to display in a specific form, and form modes can (but not necessarily) have a dedicated form controller for other custom processing needs.
Work happens
In a sandbox, see http://drupalcode.org/sandbox/yched/1736366.git/shortlog/refs/heads/2014...