Interface NodeGraph

Node Graphs

A NodeGraph holds data whose records are related as a graph rather than a tree: each node may have any number of parents and children, two nodes may be related by several edges, a node may be related to itself, and relations may run in a circle. Organization charts with dotted-line managers, workflows whose steps loop back, data models whose tables reference each other, and dependency networks are all graphs of this kind.

The model and its views. The graph itself holds the nodes and the edges, and answers questions about them: which nodes are within some number of steps of a node ( getReach()), the shortest route between two ( findPath()), the most referenced node ( getMostReferenced()), a layering for drawing ( getRanks()) and others. To show the graph, ask it for a NodeGraphTree - a live Tree view of it from one node, the focused node - with getTree(), and give that view to a TreeGrid or any other component that shows a Tree. A graph can have any number of views, each with its own focus, direction and filters, so one panel can show who reports to a manager while another shows the chain of command above an employee. Every view follows changes to the graph.

Edges and direction. An edge is a record naming the node it leaves in edgeSourceField and the node it leads to in edgeTargetField; nothing else about it is assumed. Queries and views follow edges in a direction: "out" from source to target, "in" from target to source, or "both".

Views of a graph. A view lists the nodes it reaches from its focus in one of three modes: each node once ("spanning"), each node under every node one step nearer the focus ("shortestPaths"), or every node under every parent it has ("dag"). The last two are shown as a multi-link tree. A view shows the graph's own node records, so a value changed on a node is the same in every view. Because no tree can hold a loop, an edge that closes one - leading back to a node above, or, in a view following edges both ways, joining two nodes the tree places apart - is shown as a marked leaf, a back reference; two edges between the same pair of nodes are two rows ( NodeGraphTree.showParallelEdges), and getLinkEdge() tells which edge a row stands for. Open folders and grid selections are kept when the graph changes.

Filters. Queries and views can be limited to some edges and nodes, by a function ( edgeFilter, nodeFilter) or by AdvancedCriteria ( edgeCriteria, nodeCriteria), or both, in which case both must pass. Criteria are evaluated by the framework's client-side filtering, so a view described by criteria can be saved and restored as data.

Data from DataSources. Given a nodeDataSource and an edgeDataSource, a graph loads every node and edge, follows every change made to either DataSource anywhere in the application through standard cache sync, and sends its own changes ( addEdge() and the like) to the DataSources.

Editing through a view. With NodeGraphTree.canEditStructure, dragging a row to another parent, dropping a node in from another component, or deleting a row in a TreeGrid changes the graph's edges, and every view follows.

Samples. Each shows a different side of the feature:

• Multi-Link Tree (Org Chart): an employee with a dotted-line manager appears under both managers. Two "dag" views of one DataSource-backed graph show the organization from the top down and, re-rooted on the selected employee with setFocusedNode(), that employee's chain of command upward. getLinkEdge() labels the reporting line each row stands for, edge criteria hide dotted lines, and dragging an employee onto a new manager updates the reporting line's record ( canEditStructure).
• Graph with Loops (Order Lifecycle): a workflow whose transitions lead back to earlier statuses. Views forward from the first status and backward to the selected one show each loop as a back reference and two transitions between the same statuses as two rows; findPath() gives the quickest way through, and edge criteria limit the transitions to those a role may take.
• NodeGraph Pathfinding (Flight Routes): a route network flown both ways. A "shortestPaths" view places every city under each city it can be reached through with the fewest connections and marks the routes it does not use as back references; findPaths() lists every equally short route and getReach() counts the cities within each number of connections, with an airline filter (edge criteria) and a connection limit ( traversalDepth).