Ref T9789. Transaction and Editor classes are the last major pieces of infrastructure that haven't been fully modularized.
Some of the specific issues are:
- Editor classes rely on a bunch of instanceof stuff in the base class to pick up transaction types like "subscribe", "projects", etc. Instead, applications should be adding these, and third-party applications should be able to add them.
- Code is spread across Transaction and Editor classes somewhat oddly. For example, generating old/new values would probably make more sense at the Transaction level, but it currently exists at the Editor level.
- Both types of classes have a lot of functions based on switch() statements, which require a ton of boilerplate and are just generally kind of hard to work with.
This creates classes for each type of transaction, and moves almost all of the logic to them. These classes are simpler and more focused than the old stuff was, and can organize related code better.
This starts inching toward defining CoreTransactions for features shared across applications. It only defines the "Create" transaction so far, but at some point I plan to move all the other shared transactions to Core and let them control which objects they're available for.