To understand the motivation here, imagine a UI where a marketplace is built by dragging and dropping OC resources and connecting them up visually in a diagram. Maybe assignments are arrows. This library could help support such a tool by providing insight into what what types of resources are available and how they are allowed to connect with each other.
This issue is really about improving the declarative definition of the relationships between OC resources in OCResourceDirectory.ts. There are two types of relationships - parent/child and foreign key.
-
Look into formalizing a model for a "ResourceRelationship" that could be used across parent/child and foreign key. Include if relationship is 1:many or 1:1. All parent/child are 1:many. Are there any scenarios where a foreign key relationship is 1:many? (Yes, I believe Variants to Specs is one. In fact, this is a great example of how complex this diagramming could get.)
-
Every resource that is a parent or child should include pointers to its parent and/or children. This is mostly true already, but really spell it out. Duplicate information for the sake of clarity. Add an isParent bool field. Add a parent object field with a name and field name. Add a field name to children references (even if it is always "ID"). Make sure the names of properties are very clear. Look at Variant - the most complex bc it is a parent and a child.
-
For foreign keys, spell out all the properties on this object that need to match properties on some other object. Spell out the name of that property on the other object, even if it is always "ID". As much as possible, delete the logic in custom validation functions and replace it with a declarative data model.
-
Should resources which are not assignments include an array of assignments that apply to them? I think so.
To understand the motivation here, imagine a UI where a marketplace is built by dragging and dropping OC resources and connecting them up visually in a diagram. Maybe assignments are arrows. This library could help support such a tool by providing insight into what what types of resources are available and how they are allowed to connect with each other.
This issue is really about improving the declarative definition of the relationships between OC resources in OCResourceDirectory.ts. There are two types of relationships - parent/child and foreign key.
Look into formalizing a model for a "ResourceRelationship" that could be used across parent/child and foreign key. Include if relationship is 1:many or 1:1. All parent/child are 1:many. Are there any scenarios where a foreign key relationship is 1:many? (Yes, I believe Variants to Specs is one. In fact, this is a great example of how complex this diagramming could get.)
Every resource that is a parent or child should include pointers to its parent and/or children. This is mostly true already, but really spell it out. Duplicate information for the sake of clarity. Add an
isParentbool field. Add a parent object field with a name and field name. Add a field name to children references (even if it is always "ID"). Make sure the names of properties are very clear. Look at Variant - the most complex bc it is a parent and a child.For foreign keys, spell out all the properties on this object that need to match properties on some other object. Spell out the name of that property on the other object, even if it is always "ID". As much as possible, delete the logic in custom validation functions and replace it with a declarative data model.
Should resources which are not assignments include an array of assignments that apply to them? I think so.