frodovdr/node-red
1
0
Fork 0
mirror of https://github.com/node-red/node-red.git synced 2023-10-10 13:36:53 +02:00
Code Issues Releases Wiki Activity

Updated Design: Subflow Instance properties (markdown)

Hiroyasu Nishiyama 2018-09-09 12:50:10 +09:00
parent fb0a731918
commit bd4e63ffbd
1 changed files with 43 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
Design:-Subflow-Instance-properties.md

@ -21,4 +21,46 @@ This will also feed into [[Design: Subflow Node modules]].
- This means the instance properties can only be set by any of the *static* types in the TypedInput list of supported types - including environment variables. That excludes `msg`, `flow` and `global`.
- Subflow instance properties appear as environment variables to the nodes within the subflow. This means, as you can today, a node's property can be set to the value `${FOO}` for it to be substituted with the value of `FOO`.
- We have already added in git (#dev branch) the ability to get env var values in a Function node - using `env.get("FOO")`. That will allow Function nodes to programmatically access subflow instance properties.
- A Change node (using the Env Var TypedInput type) can be used to attach any of these properties to a `msg` object passing through the flow if that is required.
- A Change node (using the Env Var TypedInput type) can be used to attach any of these properties to a `msg` object passing through the flow if that is required.
> (HN): In the teleconference held on Aug. 30th, I proposed extension of Function node (and Dashboard Template(ui_template) node) which adds interface for defining parameter input UI (details can be found [here](https://github.com/node-red-hitachi/node-red-notes/blob/master/Teleconference/20180830/FunctionNodeIF%2302.pptx?raw=true)).
> Nick-san suggested to think about integrating this proposal to Subflow Instance Property described here.
> Following is summary of my proposal on Function node extension and thoughts on its application to Subflow Instance Properties.
>
> Our use cases are as follows:
> 1. In our environment, flow developers and flow users exists and they are different person in many cases. The flow developer has JavaScript programming skill, but the flow user does not. The flow user basically perform nodes connection and parameter settings of nodes using Node-RED editor.
> In order to customize node functionalities of Function nodes with same logic, we are required to change JavaScript codes directly in current Node-RED implementation. This code change is difficult for novice flow users. So, providing parameter settings UI for each Function node instances is desirable.
> 2. We have another problem even if flow developer and flow user is a same person. When the user want to change a logic (e.g. for fixing a bug) in Function nodes containing same JavaScript code, the user needs to change codes in Function nodes and apply changes to each node. This is troublesome and error prone.
> If we can separately define parameter values, we can simply copy new JavaScript code to Function nodes.
> 3. If we provide a feature for generating independent node from Function node, we can use parameters input UI as its settings UI.
>
> Our proposal for Function node extension was as follows:
> - add a tab for defining parameters input UI and a tab for inputting parameters with defined UI,
> - UI definition consists of horizontal input items and their labels for ease of UI layout,
> - following parameters can be specified for inputting parameters:
> - one of types that can be specified for `TypedInput`,
> - selection fo types that can be specified for `TypedInput` (types can be selected on input parameter fields),
> - menu item selection,
> - checkbox,
> - no input (only shows label)
> - inputted data and related fields informations (types, labels, ...) can be accessed as Function node's property.
> - checkbox is provided to hide JavaScript editor and UI editor tab.
>
> ![Example of UI Creation](https://github.com/node-red-hitachi/node-red-notes/blob/master/Figs/UI-config-ex.gif?raw=true)
>
> As Nick-san suggested, the proposal for Function node can also applied to Subflow Instance Property.
> I think it will resolve the problems for our use cases. But I have some concerns:
>
> 1. Subflow instance properties are proposed to be accessed similar to access for an environment variable.
> My concern is how to deal with non-string data such as JSON.
> I think property input should support `TypedInput`-style input type selection.
> - Proposal 1: `env.get("FOO")` can return non-string type data,
> and `env.getInputType("FOO")` returns type of input field (if any).
> 2. If applying to subflow, I think that we sometimes needs to change parameter values of a node in subflow that can not specify environment variable (without input filed). Such case includes menu, checkbox, or other complex input items.
> - Proposal 1: make internal options of a node to be accessed as an corresponding environment variable
> (for complex input items such as TLS configuration or widget size setting, we need to extend property input mechanism with custom JavaScript?),
> 3. I think that we need a mechanism for specifying a field type if existing node in a subflow uses `TypedInput` field,
> - Proposal 1: If a type is associated with environment variable of Subflow Instance property, specify the type to typr of `TypedInput` filed,
> 4. Even if we want to create parameter settings UI for a Function node, we need to create subflow that contains single Function node. This seems cumbersome in some cases.
> - Proposal 1: add parameter definition UI for `Function` node,
> - Proposal 2: allow some shortcut for creating & modifying a subflow instance property with only Function node.