Nested Tree Mockup
def symbol
label = "Home Location"
latlong
def structure
label = "latlong"
surface
lat
long
process
distance
complicated sphere wrapping formula
EXPECTATION
On HTTP_Request
Expect .*/HOST{value="geekgene.com"}
Do
if
expr
=
x
10
then
if
expr
=
x
10
then
some proc tree
else
some other proc tree
else
if
expr
=
x
10
then
some proc tree
else
some other proc tree
With SessionInitParams
Instance = 48
This is just a quick experiment with the CSS (1 selector with 4 properties). I could probably make it sexier, but it's pretty darn readable from both text and tree perspectives, I think.
Try playing around with the width of the window and watch how the structure adapts. I don't think it's fully cross-browser compatible, but seems fine in Chrome, Firefox and IE 11 (9 and up, I think)
Noteworthy issues to consider when translating typed text to trees:
- I don't think we want to require parens when we can use syntactical context.
- For many processes, we probably want to have keywords indicate advancing to next branch (almost like parens, but not paired... we could manually pop up by typing a close_paren (or other special key) and not display the paren just change the tree formatting/placement of cursor).
- e.g. If {first-child} Then {second-child} Else {third-child}
- e.g. On {first-child} Expect {second-child} Do {third-child} With {fourth-child}
- In fact, I think we'd want to prepopulate the next child keywords and be able to tab into their slot to type (tab then press {delete} to delete optional ones like ELSE or WITH).
- Where/How do we store such keyword sequence associations? Label Table?
- It doesn't make a lot of sense to display Symbols as def trees like above. A label table view would be much more useful.
- It also seems like we could make a simple def-symbol button or something to generate those kinds of entries.
- Similarly, it seems fairly easy to build a Structure Def tool for everything up until the process defs... which is where we switch back to the coding style originally describe above. So "coding" is always for writing processes. We can make a pretty simple UI for def-building so that constructing the semantic trees for content which work slightly differently than code, don't get confused with process trees.
Possible Color Coding Approach for Semantic Tree Background Colors:
First Column (named) colors are for borders, controls, etc.Note: We probably want to use the inverted colors (right-most) so that color clarity is higher in the initial levels setting type context clearly. It also makes layering veary easy because you're always adding a new layer of transparent white. Every time you switch symbol contexts (Process, Symbol, Receptor, etc.), you start a new color context layering anew (That's why the inverted colors may make more sense.)
Second Column nested colors are for recursing tree levels. They need to be darker than expected because 10 steps of 10% opacity <> 100%
-
Process: seagreen12345678910Hand-tuned darker target:12345678910
rgba(0,100,0,.1) -
Receptor: gold12345678910Hand-tuned darker target:12345678910
rgba(190,175,0,.1) -
Protocol: tomato12345678910Hand-tuned darker target:12345678910
rgba(190,110,0,.1) -
Semtrex: crimson12345678910Hand-tuned darker target:12345678910
rgba(150,0,0,.1) -
Symbol/Label: blueviolet12345678910Hand-tuned darker target:12345678910
rgba(80,0,130,.1) -
Value/Literal: royalblue12345678910Hand-tuned darker target:12345678910
rgba(10,40,120,.1) -
Def/Structure: sienna12345678910Hand-tuned darker target:12345678910
rgba(90,60,30,.1)