Comment by lassejansen

5 hours ago

DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem.

You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g.

  <request-send url="..."> // returns response
  <response-get-text> // looks up response on the stack and returns string
  <selection-set-text> // looks up string on the stack and writes it as text content to the current DOM element.

2 comments

lassejansen

dhamidi 3 hours ago

Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary.

For example:

  lappend responses [dict status 200 body ...]

Appends a new dict to the list held in the variable responses, creating the variable if necessary.

I can see that being an attribute:

  <request-send url="..." as="greeting" />
  <response-text response="greeting" as="text" />
  <selection-set-text text="text" />

lassejansen 3 hours ago
The main reason for using a stack was reducing verbosity because for short scripts using variables felt unnecessary when the type-prefix of the command already communicates the variable contents. But it could still be a good idea to have a shorter syntax for assigned variables.
Accessing a variables works like this at the moment:
<selection-set-text $text="varname">
Keeping the dollar syntax, setting the return value to a named variable could look like this:
<response-get-text $="varname">