Simplify entity-ce-display form and AJAX logic

Agreed, and this is also necessary / a prerequisite to more easily support

• The implications of 📌 Change configuration structure for CE display 'components' Active : or not strictly the implementation of the different config schema, but after we change the UI we'll be able to add multiple formatters for the same field.
• ✨ Allow configuration of static props Active

This ticket is an unfortunate mess, at the moment. I have two independent branches:

1.

form-rows-as-components branch. We need to move away from "one row in the form == one field", because in the new paradigm enables us to add one field several times (with different formatters) and we want to support things like ✨ Allow configuration of static props Active . This branch will also clean up much of the messy comments / temporary code in the form, that was working towards this situation.

I however shelved this for now. I'm at the point where the basic properties in the form (name, formatter) rebuild and save correctly, but the plugin settings form does not show.

I will likely need to re-index the plugin settings form from "field name" to "new row name" too, and I'm not sure what issues I'll encounter there / how long they will take.

So I shelved this, and will continue working on this later (probably in a followup issue that is going to be a prerequisite for ✨ Allow configuration of static props Active if not #3446287 itself -- maybe titled "allow a field to be added multiple times").

2.

3446485-ajax branch. Form row names are still named after the fields.

• I hacked some more temporary helper code in order to build only the fields in the "Content" region (instead of all of them, as the Core form does
• (This requires EntityDisplayFormBase::form() to be copied wholesale into the form, and then changed)
• (and will very likely require a modified 'field_ui_table' form element, so I copied the FieldUiTable class to CustomElementsFieldUiTable, to be freer in hacking away the field_ui JS)
• ...and only the fields which are not in those rows, can be aded using the "Add" AJAX functionality.

However, I have not yet done anything substantial yet, like

• added an AJAX callback to the "add" select element
• untied Core AJAX functionality from the "name" row element (which should not have a callback, it just causes a bug, per the bold warning that is now on the screen)
• check how to implement the deletion. (Deletion is possible currently by explicitly selecting "Disabled" in the region dropdown, and then saving. That is obviously not good UX.)

I have 60-90 minutes more to hack on this before I'm yanked away, and then..... we'll need to plan next steps for the coming 6 days while I'm basically gone. Or: not plan, and I'll pick this up immediately as soon as I can / as I return.

Current status of the "3446485-ajax" branch (rebased on current 3.x and tidied): Two out of three points in the previous message are implemented:

• untied Core AJAX functionality from the "name" + "is_slot" row elements, so those bugs are gone.
  • I needed to clone the field_ui JS library for this, into the module - just to make one little change. But I guess we expected that already.
• I did keep the "region" dropdowns as a means for deletion, because anything else would have required hacking tabledrag.js as well. IMHO this is "good enough" and if we want an actual delete button, that would be a post-stable-release followup.
  • The "region" selector is now always shown on screen, and renamed to "Delete?". See screenshot.
  • "region" is removed from the config schema now. I think this requires no CR because this is auto-removed on save, and we never did anything with the value anyway.

Left to do: the (AJAX) functionality for adding a field to the display.

yeah, I agree changing the tabledrag.js for a better deletion XP should be post 1.0. Meanwhile maybe, "Action" would be a good name for the region-column instead of "Delete?" ?

You're right. I moved the "delete dropdown" to the right.

Things are working now. I think I tested everything.

Seems all great! Merged!

Somehow the commit ref got lost: https://git.drupalcode.org/project/custom_elements/-/commit/d3cc2c5aac56...

Automatically closed - issue fixed for 2 weeks with no activity.