In KNIME, local flow variables can be connected through special "flow ports", identified as red circles. Each node, regardless of the number input ports included, has a input port for a local flow variable.
PyWorkflow
The StringNode is currently the only FlowNode we have defined for PyWorkflow and it uses standard ports/edges as the other Nodes do. Depending on how the new "flow ports" are implemented, some back-end logic may need to change. How it currently works (on execution) is:
1) Any preceding data is loaded. This includes a node_type != FlowNode condition so only Nodes with data (not flow variables) are included.
2) FlowNodes that are defined in a Node's option_replace attribute are retrieved and passed to the node.get_execution_options() method. This retrieves the default_value of each FlowNode and creates a new Parameter that the given Node will use.
Connecting a FlowNode to another Node through a flow port does not automatically substitute the value for a given parameter. Instead, it allows the FlowNode's variable to be selected as an option to replace a parameter. Parameters include all global variables, and the optional local flow variable, as options to select from.
One proposal for how to implement this visually is this wireframe
where a flow variable can be selected through a dropdown select and enabled/disabled by a checkbox. Alternatively, an empty or blank choice in the dropdown could signify no flow variable overrides.
For the front-end to retrieve all flow variable options, the endpoint GET /node/<node_id> can be used to retrieve the current user-specified options, and all currently defined (local and global) flow variables. Node information is stored in the retrieved_node attribute, flow variables are stored in the flow_variables of the JSON response.
KNIME
In KNIME, local flow variables can be connected through special "flow ports", identified as red circles. Each node, regardless of the number input ports included, has a input port for a local flow variable.
PyWorkflow
The
StringNodeis currently the only FlowNode we have defined for PyWorkflow and it uses standard ports/edges as the other Nodes do. Depending on how the new "flow ports" are implemented, some back-end logic may need to change. How it currently works (on execution) is: 1) Any preceding data is loaded. This includes anode_type != FlowNodecondition so only Nodes with data (not flow variables) are included. 2) FlowNodes that are defined in a Node'soption_replaceattribute are retrieved and passed to thenode.get_execution_options()method. This retrieves thedefault_valueof each FlowNode and creates a newParameterthat the givenNodewill use.Connecting a
FlowNodeto anotherNodethrough a flow port does not automatically substitute the value for a given parameter. Instead, it allows theFlowNode's variable to be selected as an option to replace a parameter. Parameters include all global variables, and the optional local flow variable, as options to select from.One proposal for how to implement this visually is this wireframe
where a flow variable can be selected through a dropdown select and enabled/disabled by a checkbox. Alternatively, an empty or blank choice in the dropdown could signify no flow variable overrides.
For the front-end to retrieve all flow variable options, the endpoint
GET /node/<node_id>can be used to retrieve the current user-specified options, and all currently defined (local and global) flow variables. Node information is stored in theretrieved_nodeattribute, flow variables are stored in theflow_variablesof the JSON response.