Edit forms are currently among the least abstract -- and, theoretically, most abstractable -- parts of modern Phabricator. We have a handful of highly specialized edit forms:

• Diffusion has a paginated edit form for repositories.
• Pholio has a fairly complex drag + drop JS interaction.
• Calendar has some JS interactions between the controls.

Essentially all other edit forms are mundane collections of well-behaved fields.

The actual edits themselves are abstracted via ApplicationTransactions, but exposing the low-level transactions as usable controls is not. In practice, each EditController is mostly hand-written and defines the individual controls in the UI. Instead, we could define the fields more broadly and let the abstraction render controls, like we've done with ApplicationSearch.

Abstracting edit forms is complex, and is something I intentionally avoided doing for a long time, but previous efforts (e.g., in Diffusion) haven't been a total disaster and I think this problem is now ripe.

Increasing the level of abstraction here gives us plausible attacks on a lot of problems with edit workflows:

• (T8434 / T3320 / T8891) Templating of edit forms (hiding, reordering, defaulting fields)
• (T4768) Conflict detection and resolution
• (T5873) Generalized Conduit edit APIs
• (M1430) Stackable actions
• (T5031-ish) Draft interaction with edit actions has a messy outlook without this.
• (T4316) Per-user edit form customization? Not sure I want to go this far, but I think this is maybe better than just putting comment forms on every edit form.
• Generic batch editing across applications.