Working with Graph Hierarchies

Folding Characteristics

Folding is realized as a model-view setup, where a "managed view" presents a folding-enabled graph that is derived from the so-called master graph which holds the entire model. Both folding-enabled graph and master graph are synchronized, which in particular means that changes in one graph are propagated to the other.

There can be an arbitrary number of managed views for a given model graph, and managed views can present different parts of a graph hierarchy. For example, one managed view may present the entire hierarchy of nodes, while another only presents the contents of a given group node.

Figure 5.3, “Model-view setup for folding operations” illustrates the model-view setup with a couple of managed views that each show different content to a user. The managed view to the right presents the master graph's entire hierarchy of nodes, the managed view to the left only the contents of a group node. The managed view in the middle presents nearly the same content as the first one, however, the group node is collapsed.

Figure 5.3. Model-view setup for folding operations

Model-view setup for folding operations.

Placed central in the figure is class FoldingManager, which is responsible for providing and handling the managed views that enable folding operations in a graph hierarchy. It handles all synchronization between model and views, which in particular includes any changes to graph elements in the master graph, the so-called "original" graph elements, as well as any changes to their "representative" graph elements in the managed views.

Initially, the graph structure presented in a managed view is a copy of the master graph (or part of it), where for each original graph element from the model (or a subset thereof) there is created a representative graph element in the view. Original and representative graph element are tightly coupled, and hence, any changes to either of it is synchronized by FoldingManager, i.e., is instantly propagated to the other.


Edge-to-edge connections are not supported in a folding-enabled graph. In particular, if present in the master graph, they will be preserved, but they are not shown in any managed views.

Folding-related State Across Views

FoldingManager also creates and manages special representative graph elements which are needed due to folding operations. Although local to the managed view they are created in, these graph elements share a common state across all managed views that are handled by a specific FoldingManager, and hence are also synchronized.

Collapsing a group node in a folding-enabled graph means that its content is hidden, i.e., the grouped graph structure "disappears" from the managed view. However, when there is an edge in the master graph that connects two nodes where at least one of the representative nodes disappears from the managed view, then, in order to avoid any inconsistencies in the graph structure, the edge's representative needs to be re-directed. It is re-directed such that it connects to the collapsed group node, which ultimately is an ancestor of the disappeared node.

Figure 5.4, “Collapsing a group node” shows the content of a managed view before and after collapsing a group node.

Figure 5.4. Collapsing a group node

Collapsing a group node.

The re-directed edge in the view is still treated as a representative of the original edge from the master graph, but since it no longer connects to the representatives of the original edge's source node and target node, it is a so-called "dummy" edge now.

Similarly, the collapsed group node is also treated as a representative of the original group node from the master graph, but is in fact a "dummy" node now, because, technically, it is not identical to the initial group node representative. As a consequence, the edge that directly connected to the group node and now directly connects to the collapsed group node, is also a "dummy" edge!

Generally, any graph element that exists in a view but not in the model, or exists differently in a view, is called a dummy graph element. The following rules apply:

  • collapsing a group node makes the collapsed group node a dummy node
  • all edges that connect to a dummy node are dummy edges
  • all ports and labels at a dummy node are dummy elements
  • all ports, bends and labels at a dummy edge are dummy elements

Dummy graph elements are special representatives for which FoldingManager holds and manages separate folding-related state, which it synchronizes across all its managed views. This separate state is depicted in Figure 5.5, “Folding-related state” for the managed view in the middle of Figure 5.3, “Model-view setup for folding operations”. Note that the state for the collapsed group node (color, geometry, label text, etc.) substantially differs from the non-collapsed group node in the master graph. Also, the state for the edges connecting to the collapsed group node shows additional bends compared to the master graph.

Figure 5.5. Folding-related state

Folding-related state.

More remarkably, there is no state available for the source node of the edges. However, this is perfectly correct, because that source node actually is not a dummy node. Instead, the folding-related state keeps track of the edges's source ports.