-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIORITECHP1-27226 #256
base: main
Are you sure you want to change the base?
FIORITECHP1-27226 #256
Conversation
aggregation-cs03-release-candidate
…AP/odata-vocabularies.git into aggregation-cs03-release-candidate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much, @HeikoTheissen , starting with that.
</Term> | ||
<ComplexType Name="RecursiveHierarchyType"> | ||
<Annotation Term="Common.Experimental" /> | ||
<Property Name="ChildRules" Type="Collection(UI.RecursiveHierarchyChildType)" Nullable="false"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given an entity type that
- has a a NodeType property NT
- and is annotated with UI.RecursiveHierarchy where the Hierarchy.RecursiveHierarchy/NodeTypeProperty points to NT
Imagine NT would take three values A, B and C. How would I define that B and C can be children of A, but does not apply the other way around?
I think a ParentType is also needed, which would lead to: ChildRules is a collection of (ParentType, collection of (RecursiveHierarchyChildType))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ChildRules": [
{"ChildType": "B", "Allowed": {"$Eq": [{"$Path": "NT"}, "A"]}},
{"ChildType": "C", "Allowed": {"$Eq": [{"$Path": "NT"}, "A"]}}
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this proposal above, a single lookup is required to determine the answer for a given child node.
We can also look at it from the opposite direction like this:
"ChildRules": [
{ "ParentType": "A", "AllowedChildren": ["$In": [ { "$Path": "NodeType" }, [ "B", "C" ] ] ] } ]
With this approach, a single lookup is required to determine the answer for a given parent target node.
If the use cases at hand have a "preferred" direction, we could select the better fitting approach.
Maybe a question to @BerSie if there is such a preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then it should be ParentRules
, not ChildRules
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're so fast ... I' ve to ask at least one silly question: you are writing "{"$Path": "NodeType"}" - shouldn't it be NT instead of NodeType?
Wrt the question of direction - for the drag'n'drop use case we have the child type and with that we know which parents are possible targets (and which not). The same is valid if there is per type a create function. If there is only one create and the child type is selected later on, we have the parent type and the user can choose from the valid child types. The scenario I currently know has the first two use cases.
And there is another question - how to express the extreme cases: all children can be created under one parent, nothing can be created under one parent and all parents can serve as parent for this child type, none of the parents can serve as a parent for this child type (depending on the type of direction we choose).
https://jira.tools.sap/browse/FIORITECHP1-27226