mxGraph Structure
mxGraph creates two cells in a given graph by default. These cells are cell0 (mxGraph id of '0') at the root of the design, and cell1 (mxGraph id of '1') as it's child. Each cell has a .value field. We use the value of cell0 to store our infoDictonary, and combinatorialDictionary. We store all viewCells as the children of cell1.
Used to keep track of views that have been entered. There should always be one viewCell on the viewstack, and it should represent the root view of the design.
Used to keep track of selected cells in previous views. At the root view of the design it is empty. When entering a sub-view the selected component/module get's pushed to the selection stack.
Boolean used to determine if scars should have default width, or zero width.
There are no canonical classes related to these cells. They are differentiated based on their root style. The list of root cell types are
- ViewCell with extension of ComponentView and ModuleView
- Interaction
- MolecularSpecies
- Module
- CircuitContainer
- Backbone
- SequenceFeatureGlyph
- Text
The cell type can be determined by calling '.isCircuitContainer', 'isMolecularSpecies', etc.. as defined by the mxCell extensions in graph-base.ts.
While mxGraph may have a notion of a root of the graph at cell0, that doesn't mean it has to show only what can be seen from cell0's perspective. To that end we came up with the idea of a view cell to represent what can be seen by entering a component or module. When starting a new design a default component/module view is created, put at the top of the view stack, and shown to the user. View cells can have interactions, molecularSpecies, circuitContainers, modules, and text cells as children.
In order to find the view cell that corresponds to a sequenceFeature or module, the id of the viewCell is set to the URI of that part.
There are two kinds of view cells. Module view cells, and component view cells. Because of the way Modules and Components work in SBOL, components can't have modules, interactions, molecular species, or multiple circuit containers.
In essence this is just an edge. An edge has a corresponding InteractionInfo that's stored as that cells '.value' (prior to interaction nodes). Can only exist in module views.
An interaction on the canvas.
Available interactions.
Any of the parts under the molecular species tab in the info menu. Can only exist in module views.
A molecular species on the canvas.
Available molecular species.
Similar to a MolecularSpecies, but can be resized, and zoomed into. Zooming in takes you to a module view. Can only exist in module views.
A module on the canvas
Represents a component definition. Has a single backbone, and any number of sequence feature cells as children. Doesn't have any visualization, but does have a size.
Note that the solid black line is a backbone, but the selection boundary defines the size of the circuit container.
Basically just a straight line that's a child of circuit containers, and has sequence features sit on it.
Any of the parts under the Sequence Feature tab in the info menu. Represents a SBOL Component. can be zoomed into. Zooming in takes you to a component view.
A sequence feature on top of a backbone on the canvas.
Available sequence features.
Just a boring old textbox.
As stated previously we use the '.value' field of cell0 to store our infoDictonary and combinatorialDictionary. Each should only be modified by their respective methods in the graph-helpers.ts. (updateInfoDict, removeFromCombinatorialDict, etc...)