@paul121 and I just had a great discussion around conventions, quick forms, plans, etc, and how they relate to some of the recent discussions we’ve had with others, including @gbathree (on the forum and in phone calls), with regard to how we can “codify” conventions in a way that enables both “enforcement” (on the data input side, to ensure new records meet the requirements of a convention) and “filtering” (on the data output side, to find records that match a convention).
The outcome was:
What if we created a “convention” config entity type, to represent farmOS conventions?
Drupal has a concept of “config entities” which are basically small chunks of configuration that can be imported/exported as YML files, and then used throughout the system to build logic around them. We already use config entities for a lot of different things in farmOS.
Imagine a “convention” config entity that defines all the various aspects of a convention, including what fields/quantities are required on it, what ontologies are referenced, whether or not multiple linked records are needed, etc etc.
Lots of possibilities open up from this basic idea:
- Individual records (assets, logs) could reference which conventions they intend to follow via a
conventionbase field on them.
- Multiple conventions can be “layered” on individual records, to indicate that they follow a general convention, but also have some farm-specific convention elements as well.
- Conventions could be exported as YML files and shared in modules, or in a community repository.
- Quick forms and Plans could fill in the
conventionfield when they create assets/logs, to indicate which convention(s) they adhere to.
- Filters can be added to the UI so you can say “show me all records that match this convention”.
- API consumers can filter records by convention.
- Reports can be built that only include records that follow a particular convention (eg: the animal weight report in 1.x basically looks for weight logs using a convention).
- Audit code could be written that looks at the “intended” convention of a record and checks to see if there are any discrepancies in the record itself. This could be flagged to the user so they can make adjustments.
- The asset/log forms themselves could even go so far as to offer an option upfront when you click “Add asset/log”, which asks: “would you like this record to follow a convention?” And if you select one, then it changes the form (showing/hiding fields, making certain fields required, renaming labels, creating a fixed set of quantities, etc etc) to make the form more specific (and simple).
- … ???
The biggest question is: what would these config entities include? What is necessary to accurately represent a convention? We need to start organizing these thoughts and collecting all the use-cases we can think of in order to spec this out.
This is where the rubber meets the road.