You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the structure of Decorator and FieldItemdata fields is the wild west - you pass the JSON values directly to the model with no guardrails preventing invalid or extraneous values. As we start to consider migration tools, these constraints will become vital - for example, plugins can use them to determine if an upgrade will break any existing FieldItems or Decorators. It also provides a path for migration of these data columns. Additionally, it makes these structures self-documenting and far easier to work with and comprehend.
We have a few choices at our disposal. We could allow core & plugins to:
build DSLs for each structure using Docile (likely the most idiomatic approach)
define JSON Schemas for each structure using ruby-json-schema (likely less overhead, more portable to other languages should they want to reflect on these structures)
Let's discuss the pros/cons of each in more detail here before we come to a decision.
The text was updated successfully, but these errors were encountered:
I would 100% suggest JSON Schemas over Docile. DSLs are less explicit and harder to heard especial when distributed through out the entire application. The more clear and straight forward the information the better, and I think JSON is easier to read than a struct.
When anyone new joins the team, having a new custom made DSL would be another abstraction someone would have to learn before they can really contribute to Cortex. DSLs are rarely a good idea(sometimes they can be when included in a framework), but any other time it does nothing more than obfuscate the code.
Currently, the structure of
Decorator
andFieldItem
data
fields is the wild west - you pass the JSON values directly to the model with no guardrails preventing invalid or extraneous values. As we start to consider migration tools, these constraints will become vital - for example, plugins can use them to determine if an upgrade will break any existingFieldItems
orDecorators
. It also provides a path for migration of thesedata
columns. Additionally, it makes these structures self-documenting and far easier to work with and comprehend.We have a few choices at our disposal. We could allow core & plugins to:
Let's discuss the pros/cons of each in more detail here before we come to a decision.
The text was updated successfully, but these errors were encountered: