zippy
commented
8 years ago The proper way to do this, I think, is to actually represent trees in the editing state by wrapping their parts in the HTML that represents their structural definition, and can thus have UI associated with those parts for adding/subtracting optional elements of those parts. This has two implications:
- the generative case: when creating a new tree from scratch it means starting with just these HTML elements from the definition. For symbols with no optionality this looks like what we already did because you can just create the symbols with blank surfaces. For symbols with optionality what will appear is the little +/- UI elements.
- the editing case: when editing an existing tree, it means matching the tree against it's definition elements. To implement this means finishing #8 which would implement generating a semtrex based on a symbol's definition, and then porting that, plus semtrex matching to javascript.
Non-fixed size structures, i.e. ones with optionals need visual markers for delete/add more repetitions/change or value/choose different symbol from set, etc
This is can be deduced from the STRUCTURE_DEFINITION in the case of symbols and from the INPUT_SIGNATURE in the case of processes