A do-node and corresponding return-node for creating loops and task-lists.
These simple nodes allow you to define loops, task-lists and - as a goodie - no-ops. They help structuring your flows by preventing crossed loop-wires and endless flows. Take a look at the samples below to understand what I mean. You find the sample flows in the doc-folder as well.
Loops are the most basic usecase for the do-return-nodes. Just drag the do-node onto the canvas and wire its first output (task output) to whatever shall be repeatedly done and the second output (done-output) to where the flow shall continue after the loop ended. Using the return node you can decide whether you want to execute the loop once again (continue mode) or to end it (done mode).
Another usecase is for doing several tasks sequentially on a message. Therefore you need to add more task-outputs in the do-node (by adding tasks in its configuration). Each time a return-node in done-mode is called, it returns to the do-node and continues with the next task. Again, returning in continue-mode loops the current task.
You can abort a task-list at any time by returning in abort-mode. In the below example the balloons get painted red but in case a balloon is already red, it immediately aborts as this should not happen.
Tips & tricks
- Do-return-loops can be nested. But be careful not to mess with your flow: It can get hard to identify which return node corresponds to which do-node. For a better understanding you should name them correspondingly.
- The same tasks can be triggered by different do-nodes. The return-node knows where to return to during runtime. This can be helpful to define kind of construction plans using todo-lists which execute the same actions but in a different combination. See the 4th example (overlapping task lists) to get a better impression of what I mean.
- Aborting is an easy way for error handling within complex tasks: You might set an error-information within the msg-object and abort at any time. On the done-output of the do-node you can then check for errors and handle them appropiately or continue normally if no error-information is present.
- You might want to use todo-lists for structuring your flows top-down instead of having endless linear flows or very long return-wires.
- (Temporarily) restructuring complex tasks might get easier as you do not have to move all flows but only have to change the wires going out from the do-node.
- A do-node with no task is called a no-op-node and might help to create many-to-many-connections without having to use a function-node (thus easier to realise and maybe visually more appealing).
- Attention: Do not leave outputs unconnected! If no return node is connected to an output, this output will stop the flow. Also: If an output only ends in continue-nodes, you will build an infinite loop. Thus, each output should end in a 'done' sometime.
- Basically everything could be achieved using link-nodes. Anyway, IMHO they would make the flow more cluttered and less readable.