Feature Request: Nested Ports

[philip-alldredge]

I would like to see the ability to have ports which are contained in other ports. Both the outer port and the inner ports should be useable as an edge end. This capability should allow for arbitrary level of nesting. The inner ports themselves could be positioned relative to the outer ports.

I am currently using fixed position for ports as a way to layout such diagrams. However, that has limitations such as the ones described in #272 and prevents allowing ELK to determine the best position for the ports.

[le-cds]

Philip, could you provide us with some kind of an example? I'm trying to get a feel for what nested ports might be exactly and how they might be used in a visual language.

[le-cds]

Oh, and to add to that: why does #272 stop you from simulating nested ports using FIXED_POS port constraints? You just need to make sure that all edges connect to explicit ports, which wasn't the case in the example you provided.

[philip-alldredge]

The Architecture Analysis and Design Language (AADL) is a language where this is useful. It has standardized textual and graphical representations. See below for an example image.

On the right of the "hw" component there is an AADL "feature group" named sensor_data. Feature groups can contain multiple types of "features" including other feature groups. In this case it contains 2 AADL ports. Those ports are connected to ports contained in nested model elements and the feature group itself is connected to another feature group.

AADL: https://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language

[philip-alldredge]

To clarify my issue regarding #272:

We currently use fixed ports to simulate the nesting ports. It results in a mostly positive result.

Due to #272, we currently can't layout the edge if it connected to a node that has a port. As you stated in the issue, the solution is to connect the edge to a port. I don't find this requirement to be unreasonable. Like you said, it is considered a part of using FIXED_POS ports by ELK. However, since the graphical language is fixed in our case, we would need to pre-select the location on the node where the edge should connect and create a dummy port.

If ELK supported these types of nested ports directly, then our need for using fixed ports would be eliminated. We could use FIXED_SIDE or FREE and let ELK's algorithms place the ports.

[uruuru]

Would it be possible for you to model the _featuregroups as nodes where only the actual connection points of edges are ports? I presume a requirement of feature groups is that they have to touch a hierarchical node's boundary?

[philip-alldredge]

I don't believe so. Yes, feature groups must touch a hierarchical node's boundary. The group itself can be connected to both inside or outside the containing node. In the example above, hw's feature group itself only has a connection sw's feature group but it could have a connection to a node inside of hw.

[philip-alldredge]

Even if the nested ports were not positioned optimally, it would still be a signficiant benefit to have these nested ports.

A related topic is having multiple port anchors for the same port. In our case, the port graphics have a different anchor depending on whether the connection is internal or external to a component. We currently set the port anchor to the point on the graphic between the two actual connection points. This works fine, but if there was a way to have multiple anchors and assign the anchors as start and end points for an edge, that would be great. We could use that capability for the feature groups as well.

Of course, actually implementing something like that in ELK sounds like it could be a big task.