Node Types
In many use-cases, node elements are associated with specific types. There are several ways to highlight elements of different types, for example, by using a particular shape or color. To further emphasize types, node placement can be restricted during the layout calculation, for example, by using group nodes or swimlanes to separate nodes of different types. These kinds of drawing constraints can significantly impact the result, which might not always be desirable. The more lightweight node types feature presents a solution for this. Algorithms that support this feature usually have some flexibility for placing the nodes, which can be used to prefer placing nodes of the same type closer to each other without excessively affecting the overall layout result.
Declaring node types is done by associating an arbitrary object with the nodes via a Layout Data property called NodeTypes.
For example, to define node types for the hierarchical layout, see nodeTypes.
Nodes that are associated with the same object instance are considered to be of the same type.
The type is generally treated as a secondary optimization criterion. Thus, nodes of the same type are not simply clustered together. The type is only considered when some flexibility is available after considering other constraints relevant to the layout algorithm (like minimizing the number of crossings or considering the hierarchical grouping structure).
Layout support for node types lists the layout algorithms that support node types. Defining node types has no effect on other layouts. In the following sections we describe in more detail how the various layouts handle node types.
| Layout Style | Class Name | Note |
|---|---|---|
Hierarchical Layout
The HierarchicalLayout class uses the types of the nodes as a secondary criterion when ordering nodes within their layer. It attempts to place nodes of the same type next to each other if this does not cause additional edge crossings or conflicts with other constraints such as groups, swimlanes, or sequence constraints. The algorithm uses an additional local optimization heuristic to improve the placement with respect to node types and, therefore, does not guarantee optimal results. Also, this extra step may increase the required runtime. The node types do not affect the layer assignment.
Organic Layout
In the OrganicLayout class, the node type affects the detection of substructures, such as star structures, cycles, and chains. If types are defined, each substructure either consists of nodes that all have the same type or only of nodes without a type. For parallel and star structures, the organic layout also offers the option to turn off this strict separation. When disabled, types are still considered, but only within a structure to, for example, improve the ordering of nodes. See the properties parallelSubstructureTypeSeparation and starSubstructureTypeSeparation.
Orthogonal Layout
Similar to the organic layout, the OrthogonalLayout considers node types to strictly separate substructures. The types do not otherwise affect the orthogonal layout algorithm.
Tree Layout
The TreeLayout uses the node types as a criterion when there is no user-specified child order (TreeLayoutData.childOrder). In such cases, the algorithm places siblings of the same type next to each other.
Note that some subtree placer implementations have placement criteria that are stronger than node types. For example, the CompactSubtreePlacer optimizes compactness, and this remains the main goal even when types are defined. Hence, nodes of the same type might not be placed next to each other.
Circular Layout
To support node types in the CircularLayout, ensure that the nodes of a circle partition are sorted according to their type. This feature is disabled when enabling the from-sketch mode (fromSketchMode) or defining a custom node order (nodeComparator).
Component Layout
The ComponentLayout class considers node types when arranging components. If all nodes within a component share the same type, the component is considered to be of that type. Components with the same type are preferably placed next to each other. The arrangement styles most suitable for node types are ROWS, SINGLE_ROW, SINGLE_COLUMN, and MULTI_ROWS_TYPE_SEPARATED.
The style MULTI_ROWS_TYPE_SEPARATED is specifically designed for use with node types. It ensures that each row contains only nodes of the same type. In other respects, the style uses the same strategy as MULTI_ROWS.
Radial Tree Layout
The RadialTreeLayout arranges the out-edges of a node based on the type of the edge’s target node. When node types are defined and a custom child order (RadialTreeLayoutData.childOrder) is not specified, all children of a node that have the same type will be placed together around their parent node.
Radial Layout
The RadialLayout class uses node types as a secondary criterion for arranging nodes on the same circle. Specifically, for nodes on the same circle (i.e., within the same layer), the algorithm attempts to place nodes of the same type adjacently, provided that this does not introduce additional edge crossings or conflict with other constraints.
Note that the algorithm employs an additional local optimization heuristic to refine the placement based on node types. As a result, optimal results are not guaranteed, and the required runtime may increase. The node types do not influence the layer assignment in any way.
