- It tries to fetch an EntityFormDisplay in init()
This ends up creating a fresh EntityFormDisplay object for no reason (caused weird bugs in #2144919: Allow widgets and formatters for base fields to be configured in Field UI)

- It calls field_attach_*() / field_info_extra_fields()
Might be problematic when #2095195: Remove deprecated field_attach_form_*() tries to replace them with more EntityNG code.

- It calls $form['#entity_builders'] callbacks - do those have any interest on config entitites ?

Looks like the repartition of code between EntityFormController & ContentEntityFormController needs some love :-)

Comments

yched’s picture

Title: EntityFormController does things that are really only targeted for ContentEntities » EntityFormController does things that only make sense for ContentEntities
Issue summary: View changes
Issue tags: +entity API
andypost’s picture

also processForm() tries to assign weights for components but this task should live in display itself

yched’s picture

"should" not necessarily, but "could" yes. The Display objects are currently only a repository of display settings, but there's a long running thought that possibly some of the rendering logic might move in there too.

Separate issue though. Even if we did that, then there would be code in EFC that calls $display->orderTheThings(), and this only makes sense for ContentEFC.

yched’s picture

Status: Active » Closed (duplicate)

#2095195: Remove deprecated field_attach_form_*() is going to clean that. Closing this one as a dupe.