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
The proposed undo system would be part of AbstractGraph.js. Every time an action is performed (such as removing a node, adding children, etc), that action is logged and stored in an undo stack, which would allow AbstractGraph to undo that action at a later time via an undo() method. Such a system would have the following benefits:
Speed: Currently, when a transformation is removed, you need to re-apply all other transformations from the beginning. With the undo system, you'd only have to undo what is needed.
No need to clone the model graph. Currently, to generate the visualization, the initial model is cloned and transformations are applied to that clone. This unfortunately means that any references to nodes in the original graph is useless. For example, imagine there's a transformation that removes a single node. The natural way to implement that would be to create a new transformation class that takes a node as a parameter. However, that wouldn't work, since the node passed to the parameter is a node in the original, not the cloned graph. With the undo system, we no longer have a need for the clone; we can just undo all changes if we want to revert back to the original.
[Issue created by pqperry: 2014-08-29]
The text was updated successfully, but these errors were encountered:
The proposed undo system would be part of AbstractGraph.js. Every time an action is performed (such as removing a node, adding children, etc), that action is logged and stored in an undo stack, which would allow AbstractGraph to undo that action at a later time via an undo() method. Such a system would have the following benefits:
Speed: Currently, when a transformation is removed, you need to re-apply all other transformations from the beginning. With the undo system, you'd only have to undo what is needed.
No need to clone the model graph. Currently, to generate the visualization, the initial model is cloned and transformations are applied to that clone. This unfortunately means that any references to nodes in the original graph is useless. For example, imagine there's a transformation that removes a single node. The natural way to implement that would be to create a new transformation class that takes a node as a parameter. However, that wouldn't work, since the node passed to the parameter is a node in the original, not the cloned graph. With the undo system, we no longer have a need for the clone; we can just undo all changes if we want to revert back to the original.
[Issue created by pqperry: 2014-08-29]
The text was updated successfully, but these errors were encountered: