Workflow design for widget interface: subclass, wrap, or neither?

[SimonHeybrock]

#58 describes some concerns about whether workflows in technique-packages should subclass or wrap Pipeline, which both have problems. I have had a closer look and think there may be a less invasive solution, closer to the current one (where the named workflows are simple functions returning a sciline.Pipeline instance).

What the UI/widgets and parameter creation actually needs is the following:

1. Defaults the get set in parameter creation. -> Why can't this use the values the workflow creation set on the pipeline? This would avoid double bookkeeping.
2. List of typical outputs -> Could be stored as attr on the Pipeline instance?
3. Special setters performing map-reduce -> We have have already discussed storing such a callback in the Parameter instance, this would probably address this?

Did I forget anything? With the above we could:

• Keep workflow (pipeline) creation functions as they are (return Pipeline instance, not a subclass), simply store typical outputs as attr of the instance.
• Somewhere in the package, define common as well as workflow-specific parameters (similar to current prototype, we are already using a shared free function).
• Create parameters using some helpers (no link to workflow/pipeline instance required, the workflow can be passed ("injected") into the param factory.
  • Can use default from workflow.
  • Create auto-params (based on types) for workflow requirements (nodes without values or inputs) that do not have a configured parameter.
• No changes for users (and our code + unit tests), they still work with Pipeline directly.

An additional advantage is that this is probably keeping the other options open for later, since most of the pieces could be reused.

[SimonHeybrock]

Done in prototype branches.