ApplicationEditor is now largely stable and new third-generation Conduit endpoints have taken shape. Subprojects are up next.

ApplicationEditor

This week mostly involved more work on ApplicationEditor (see T9905). Although it hasn't changed much from last week, there were a lot of rough edges and unpolished areas which are now in better shape. T10004 has some of the particulars.

A lot of these changes related to cleaning up minor, long-standing issues in areas of the codebase adjacent to ApplicationEditor. For example, default values should work properly with custom fields now, and ApplicationEditor workflows should generate better, more tailored transactions when creating objects.

These changes are generally in good shape but were still landing as of yesterday, so I want to let them settle for another week before promoting them to stable and the Phacility cluster.

Conduit

One of the adjacent areas of the codebase that was updated was Conduit query endpoints: I've introduced new *.search endpoints as companions to the new *.edit endpoints. Roughly, Conduit endpoint generations are something like this:

• Generation 1, *.info
• Generation 2, *.query, *.create, *.update
• Generation 3, *.search, *.edit

The first generation endpoints had severely limited power and generally were replaced by the second generation fairly quickly.

The second-generation endpoints were essentially hard-coded copies of whatever the web workflows were doing and/or whatever arc needed to do. This was often a fairly reasonable amount of functionality, but also often much less functionality (and sometimes slightly different functionality) than that provided by the main web workflows.

The third-generation endpoints position the web workflows and conduit workflows as thin layers on top of underlying EditEngine and SearchEngine implementations, which drive all the logic and behavior for both workflows. Applications now define searchable and editable fields and they are automatically exposed via Conduit and the web. In practice, this means the third-generation endpoints are much more powerful and usually pick up application changes automatically. For example, if we define a new search field in the web UI, it is automatically and immediately available in Conduit, too.

I made a blog post elsewhere (Reading and Writing Paths in Owners) with an example of how to do a read and a complex write using these new endpoints. See that post for additional pointers to new documentation.

With the advent of these new endpoints, we will deprecate the old ones at some point in the relatively near future and eventually remove them. For most callers, swapping endpoints should be straightforward, as the new endpoints should offer a strict superset of features in essentially every case and be far easier to work with. I also improved some of the tooling for administrators to make it easier to find callers invoking deprecated endpoints, see Managing Conduit Changes.

Subprojects

Subprojects are the next major thing I'm planning to work on, although I may not build them out too aggressively before next week's promotion to stable since I don't want to miss it because Projects are in shambles. So this will probably be low-impact setup work this week, then serious work next week.