This is a historical document (from November 2016). It may have some out of date terms or other idiosyncrasies compared to updated documents like Use Cases or the Class Diagram.
I have established that Node is probably the most important class here. A syntax tree is composed of nodes and an overwhelming majority of the operation involve interactions between Nodes. The noun ‘textbox’ is referring to the visual representation of a node in the GUI, so we can encapsulate that within the Node class. Similarly with the border or highlight. As to the various types of nodes, these are best represented as Node instances with different properties and relations to one another.
The second most important class here will be the (syntax) Tree class. It will serve as a way to hold the nodes as a mapped collection rather than what amounts to a linked list. It will also serve to hold methods that operate on large numbers of nodes in a non-transversal way, such as retrieving nodes at a certain offset from the root. Furthermore, it can carry state variables such as the currently selected node.
The user is the user, and within the syntax tree drawer itself there is no reason to represent them in code (this will change when it comes to the website itself).
The GUI itself can be thought of as several components, specifically the SVG workspace and the elements within it, the Snap.svg javascript library which allows for easier SVG manipulation, and the various functions of jQuery which allow for other visual manipulations. It remains to be seen whether having these various visual tools encapsulated in a single class would be useful. As of now they exist as an implicit layer in between any underlying classes and the output the user sees. Of particular concern are event listeners, which can also be thought of as part of the GUI, but have no real home in the code as of now.
Things like present, display, and show are represented in the system by the interactions between the code and the actual SVG elements. This interface operates at a level below the classes we’re concerned with, utilizing things like jQuery, Snap.svg, and even plain Javascript.
Press suggests an event coming from the user. Such events are listened for by the Workspace class, which then send the event to the relevant instance of Tree using callback (for example, Tree.eventEnter).
Create is simply making a new instance of an object.
Confirm corresponds almost directly to Node.save().
Shift can be thought of as passing arguments to Node.position() to change that position.
This is a historical document, from November 2016. It may have some out of date terms or other idiosyncrasies compared to updated documents like Use Cases or the Class Diagram.
Several of these are clearly graphical elements (button, alert) that really don’t have a clear place to reside in the class diagram as it is. There are several graphical elements so far, existing as properties of Node and Workspace and Branch. The issue is further complicated by the fact that things like buttons may be implemented as HTML elements rather than SVG elements. It is likely that Button would be a good class, and possibly Alert as well (although this might also be a method of Workspace). In any case, it is clear that some restructuring will be needed to accommodate the multiplication of graphical elements.
“File dialog” should not need to be represented in our custom code, as it is built into the browser and we are just accessing it. Custom dialogs, on the other hand, (see exporting use cases) will likely need their own class. This would suggest that having Alerts be a method of Workspace is not the right way to go, and instead we might want to lean towards something like an overarching Modal class (which has child classes Alert and Dialog and etc.).
Menus are yet another graphical element that needs to be handled. Perhaps we need to simply make a Graphic class, from which all graphical elements that need to be represented in code can use. At the very least, such a class for controls (as opposed to pieces of the tree) might be a good idea.
The “shadow” tree is particularly difficult. At first it might be tempting to think of it as a method of Tree, but the fact is that it can be called on subtrees as well and how are we to deal with that? It is obviously ridiculous to make every subtree a Tree with it’s own shadow method (consider the number of possible subtrees for even a moderately sized Tree). Potentially this shadow tree could be categorized as a graphical interaction and thus handled by Workspace or another graphical management class.