You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The architecture of Dynamo was previously a tangled mess of dependencies. This PR refactors DynamoCore into a modular, layered architecture, where the boundaries of the various components of the application are clearly defined.
Or, in a nutshell, we are no longer accessing DynamoModel from remote parts of the application. This means that:
In order to test parts of the application, we don't need to create an entire instance of the application.
We can safely assume that different parts of the application aren't affecting other remote parts of the application unless there is a direct dependency between the two components.
What's been changed?
XML parsing
The logic for loading whole Workspaces, Nodes, Connectors, and Notes are now all located in a single place: NodeGraph
Loading .dyn and .dyf files now leverage this new API, previously we had duplicate (and unsynchronized) code for loading both.
Node instantiation
NodeFactory has been overhauled; previously we were doing weird string parsing to determine how to create new nodes. Nothing was consistent, the API was cumbersome to use, and there was a ton of duplicate code.
All node instantiation is now processed through NodeFactory. Different types of nodes register INodeLoader instances with the NodeFactory. For special kinds of nodes (Custom Nodes and Zero Touch Nodes), there are special INodeLoaders that handle the necessary extra logic for creating instances. This means that NodeFactory no longer needs to know about the Function and DSFunction classes.
All external implementations of Nodes which extend NodeModel are now instantiated using a pre-compiled Expression, as opposed to relying on an Activator. This means that instantiating large numbers of new nodes should be significantly faster (copy/paste, undo/redo, loading files).
Custom Node Infrastructure
CustomNodeManager has become the primary interface for dealing with Custom Nodes.
It keeps track of CustomNodeWorkspaces, instead of just CustomNodeDefinitions.
CustomNodeWorkspace now emits events when the CustomNodeDefinition and CustomNodeInfo has changed.
This makes sense because the state of a CustomNodeWorkspace defines what the CustomNodeDefinition and CustomNodeInfo are.
These events are watched by CustomNodeManager, which then forwards them to DynamoModel, which then propagates them to the EngineController, Search Library, and Custom Node Instances.
Custom Node (Function) Instances are now created from CustomNodeManager, in order to ensure that they are kept in sync with their CustomNodeDefinition.
Evaluation
Since HomeWorkspaceModels are the only kind of Workspaces that can be evaluated, EngineController has been moved to HomeWorkspaceModel
Consequentially, all logic originally on DynamoModel associated with EngineController has now been moved to HomeWorkspaceModel Unfortunately, CodeBlockNodeModels have a dependency on EngineController for Auto-complete. Further work can be done to decouple Auto-complete from EngineController, which would allow for total removal of EngineController from DynamoModel.
This sets the stage for eventually having multiple HomeWorkspaceModels active at once.
Search
Search has been re-implemented to be as general as possible.
Search has been refactored to support the new method of instantiating Nodes.
The actual search method has been separated from the categorization infrastructure.
Categorization of Search Elements has been greatly generalized and simplified.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Big Idea
The architecture of Dynamo was previously a tangled mess of dependencies. This PR refactors
DynamoCore
into a modular, layered architecture, where the boundaries of the various components of the application are clearly defined.Or, in a nutshell, we are no longer accessing
DynamoModel
from remote parts of the application. This means that:What's been changed?
NodeGraph
NodeFactory
has been overhauled; previously we were doing weird string parsing to determine how to create new nodes. Nothing was consistent, the API was cumbersome to use, and there was a ton of duplicate code.NodeFactory
. Different types of nodes registerINodeLoader
instances with theNodeFactory
. For special kinds of nodes (Custom Nodes and Zero Touch Nodes), there are specialINodeLoaders
that handle the necessary extra logic for creating instances. This means thatNodeFactory
no longer needs to know about theFunction
andDSFunction
classes.NodeModel
are now instantiated using a pre-compiledExpression
, as opposed to relying on anActivator
. This means that instantiating large numbers of new nodes should be significantly faster (copy/paste, undo/redo, loading files).CustomNodeManager
has become the primary interface for dealing with Custom Nodes.CustomNodeWorkspaces
, instead of justCustomNodeDefinitions
.CustomNodeWorkspace
now emits events when theCustomNodeDefinition
andCustomNodeInfo
has changed.CustomNodeWorkspace
defines what theCustomNodeDefinition
andCustomNodeInfo
are.CustomNodeManager
, which then forwards them toDynamoModel
, which then propagates them to theEngineController
, Search Library, and Custom Node Instances.Function
) Instances are now created fromCustomNodeManager
, in order to ensure that they are kept in sync with theirCustomNodeDefinition
.HomeWorkspaceModels
are the only kind of Workspaces that can be evaluated,EngineController
has been moved toHomeWorkspaceModel
Consequentially, all logic originally onUnfortunately,DynamoModel
associated withEngineController
has now been moved toHomeWorkspaceModel
CodeBlockNodeModels
have a dependency onEngineController
for Auto-complete. Further work can be done to decouple Auto-complete fromEngineController
, which would allow for total removal ofEngineController
fromDynamoModel
.HomeWorkspaceModels
active at once.Reviewers: