Does it make sense for a template to have an ID? Initially, the argument for a template.id was for symmetry with variable.id. However, perhaps a user might want to bookmark the URL for a specific template in order to come back to that part of the form later? This could be useful for very involved form filling wizards. At any rate, the template.id should be optional.
We should eventually add support for template scripts. This will make it easier to make step by step wizards where each step runs a script. The script takes whatever is in the input_folder and saves files in any of the step folders (input, output, log, debug). The script can update input variables and thus affect which template appears next. From a design perspective, I want to avoid goto statements to prevent spaghetti template logic.
input:
templates:
- id: a
script:
path: a.py
- id: b
script:
path: b.py
- id: c
script:
path: c.py
expression: a < b
- id: d
The problem with the above design is that there is no way to register the output of the script. We want to be able to use each tool as a building block to make more complex tools.
Below we explore ways to support tools as individual building blocks in a text based syntax. I like the symmetry of option 2, but we might be too far committed to option 1 at this point.
Option 1
Here the variables and templates are part of the input section. But what if the user decides to specify a tool as part of an output template?
input:
variables:
- id: a
view: number
path: variables.dictionary
- id: b
view: number
path: variables.dictionary
- id: c
view: number
path: variables.dictionary
templates:
- path: a.md
- path: b.md
tool:
uri: /t/add-numbers
- path: c-negative.md
expression: c < 0
- path: c-zero.md
expression: c == 0
- path: c-positive.md
expression: c > 0
I suppose sub-tools could be supported for both input and output. The log templates remain untouched and this syntax only overrides the input and output templates / user experience.
However, perhaps this syntax is too simplistic. What if it is possible to go in multiple directions from one template? And what if the author wants multiple tools to run from one template? All of the above is technically currently supported if the author wants to write some raw javascript.
Option 2
Here the variables and templates are brought to the outermost level. We lose the structure of input vs output in exchange for symmetry. It may be possible to jump to specific templates of a result under this syntax.
variables:
- id: a
view: number
path: variables.dictionary
- id: b
view: number
path: variables.dictionary
- id: c
view: number
path: variables.dictionary
templates:
- path: a.md
- path: b.md
tool:
uri: /t/add-numbers
- path: c-negative.md
expression: c < 0
- path: c-zero.md
expression: c == 0
- path: c-positive.md
expression: c > 0
/t/add-numbers/r/1-2/i # template 0 of input
/t/add-numbers/r/1-2/t/a # template a
/t/add-numbers/r/1-2/t/c-zero # template c-zero
Conclusion
Maybe we do not need to further complicate the current configuration file format at this time. Instead, perhaps we can add more client side syntactic sugar to calling other tools inside a template. In that case, the current syntax is sufficient to cover the case of a tool that calls other tools as part of its step-by-step input or output wizard.
If we add support for sub-tools, it will be in the form of javascript functions/classes rather than yaml syntax.