What the Field UI does currently is still modeled after the D7 architecture:
- define routes for "Manage display [view_mode]" pages,
- use access callbacks to only show those where the view modes uses "custom settings"
- in the page callbacks, show a form collecting various stuff and save them where appropriate on submit.

The D8 situation is that those "Manage display" pages really are "where you edit an EntityDisplay entity".
So the EntityDisplay object should be loaded by the route as part of parameter upcasting (in a way that the upcast would fail if status = FALSE --> 404), and received as an argument in the form builder (instead of currently: the form builder receives the raw URL parts, and at some point goes "I'll load an EntityDisplay object because I'll do stuff with it").
(and same for form displays of course)

An additional step might be to make those forms be the actual, official "Entity forms" for the EntityDisplay entity types (in the Entity API sense), but that might be a bit harder since the entity types are provided by entity.module while the forms are provided by field_ui.

Comments

Assigned:Unassigned» swentel

Assigning to me

Awesome idea! +1

Suppose better to make field_ui module to inject form controller into EntityDisplay and EntityFormDisplay like menu_entity_info() does for menu config entity

This should allow to use $this->entity and native entity form, just pass additional arguments via routes

Moving forward on this might make #1875974: Abstract 'component type' specific code out of EntityDisplay easier.
@swentel, do you still intend to work on this ?

Ooh crap, completely forgot about this one. I can't work on this before next monday or so.

Assigned:swentel» Unassigned
Issue summary:View changes

OK - unassigning for now then ?

Status:Postponed» Active

Suppose better to open the issue again, this one just need bits of #1963340: Change field UI so that adding a field is a separate task to decouple OverviewBase from DisplayOverviewBase

From the OP:

An additional step might be to make those forms be the actual, official "Entity forms" for the EntityDisplay entity types (in the Entity API sense), but that might be a bit harder since the entity types are provided by entity.module while the forms are provided by field_ui

It would actually not be really new : Field UI already provides the "entity delete form" for FieldInstance config entities & the "list controller" for Field config entities.

IMO that's what we should shoot for here - make the "Manage Display" & "Manage Form" pages the actual entity forms for EntityViewDisplay & EntityFormDisplay config entties.