Skip to content
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

Draft
wants to merge 14 commits into
base: main
Choose a base branch
from
Draft

FIORITECHP1-27226 #256

wants to merge 14 commits into from

Conversation

HeikoTheissen
Copy link
Contributor

@HeikoTheissen HeikoTheissen requested a review from BerSie May 25, 2023 12:46
@HeikoTheissen HeikoTheissen changed the base branch from main to aggregation-cs03-release-candidate May 25, 2023 12:47
vocabularies/UI.xml Outdated Show resolved Hide resolved
Copy link
Member

@BerSie BerSie left a 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">
Copy link
Contributor

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))

Copy link
Contributor Author

@HeikoTheissen HeikoTheissen May 26, 2023

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"]}}
]

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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).

Base automatically changed from aggregation-cs03-release-candidate to main October 20, 2023 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants