Replies: 1 comment
-
Hi @JonasL5, thank you for your question! Unfortunately, there is no out-of-the-box support for non-binary edges in Sprotty and thus in GLSP client. That being said, it should still be possible to implement with a certain amount of custom code and extensions of default behavior. As there are several parts in Sprotty that expect binary edges (with exactly one source and one target), I assume the most straightforward way of implementing multinary edges is to translate them into multiple binary edges. Therefore I suggest to create one "center-element", which acts as target of all involved binary edges. For each involved connected element, you have then exactly one edge that has the connected element as source and the "center-element" as target. Of course you'd still need to customize the select command to auto-select the entire multinary edge if one of its elements is selected. Also you'd need to implement custom editing tools (probably based on the existing ones) that allow to create such multinary edges and change their targets or their routing, if needed. Adding "native" support (ie by not simulating multinary edges via binary edges) would require quite a lot of custom code, as there are many aspects involved: GModel type to represent more than one source and target (routable elements can only store a source and a target), the routing and layouting, which only expect binary edges, etc. I hope this helps a bit to get started! |
Beta Was this translation helpful? Give feedback.
-
Hi everybody,
Would anyone know if it'd be possible to implement an edge with a non-binary cardinality (like hyperedges that account for m:n cardinality, or more specific structures)? What about the selection of the hyperedge, or its composite "edges", within the client and the representation and operations on such element?
Beta Was this translation helpful? Give feedback.
All reactions