PoC - A Registry-Based Approach To The Fields API

[alexstandiford]

This is a very early look at a potential solution to the fields API. This is not ready for actual review. I'm pushing early mostly so we can talk about some of the things in the PR and see if there's significant problems.

Approach

The idea here is that there is a central singleton registry that registers four different things (we could potentially split this up if it makes sense, the class is getting kinda big).

Control and Datastore Types

The idea here is that there is an associative array of registrable "types", which get associated with a PHP class that handles that actual type. I did this so that it's possible to specify a type in the JSON file, and the API knows that option correlates with the Option class. This is important because if the class name changes, or the namespace changes, we don't want to force people to need to change the JSON to continue supporting it.

Controls

A control is intended to be what provides the information necessary to actually render the field. My thinking is that we may be able to have a REST API endpoint that utilizes the control data to actually provide the information about the field so that JavaScript can render the content, or PHP if it's a back-end based item.

Datastores

A datastore is responsible for the crud operations of the field.

Strategies and Repositories

This entire thing can be summarized as a repository (Field_Registry) of strategies (Controls, Datastores). These strategies are accessed using the strategy with an ID, and then can be used to do the tasks that each strategy is designed to do.

The repository does not make class instances on registration, but instead uses a hydration-like approach where an array of data gets instantiated as the correct class when it is accessed. This ensures that the actions and everything related to each field is only called when that item is requested.

Concerns so-far

Right now, there's a way for both datastores and strategies to "do actions" when registered. This allows each one to do certain things that are necessary when they get registered on the back-end. This may cause confusion in cases where the field is accessed too late in the process since those actions wouldn't get registered until after their actions are called. I think this is relatively easy to work around, however.

I have this set to support multiple controls, since one datastore could potentially be controlled in multiple locations. The unfortunate side-effect of this is that I have to provide both the field ID and the control ID to be able to locate the control. I generally dislike this, and would love to come up with a good solution that avoids this.

[lkraav]

What's the next step here?

[sc0ttkclark]

Archived code to https://github.com/sc0ttkclark/wordpress-fields-api-2023