I noticed a strange behavior when trying to drag a node from the Node Repository onto a connection that is upstream of a node in paused or queued state:
If you try to drop a node onto the second connection here, it first seems to work and you get a dialog asking for confirmation:
After clicking OK however, nothing happens, which is a bit counter-intuitive.
Maybe the behavior can be improved, either by showing a more informative message in the dialog, or by disallowing the drop behavior in the first place, and showing an icon indicating that this action is forbidden at the current state.
Similarly, I’d suggest to disallow drag-and-drop when the dragged node has an incompatible set of input and output ports, as otherwise you can end up with a lot of lost connections that can be hard to rewire in complex workflows.
What do you think about these suggestions?
These both seem like bugs - definitely the former, and the latter depending on what you mean by ‘incompatible set’ - if you mean that the node being replaced by the drop has input ports of type (A, A, B) then the node being dropped on it must also have (A, A, B) i would be inclined to disagree; if you mean that the node being dropped on it must have at least one A or one B, then i would agree (and this should be the currently implemented strategy.)
Please clarify the ‘incompatible set’ notion for me, and i’ll investigate and open JIRA tickets as appropriate.
Thanks @quaeler for the quick reply!
What I meant: it is currently possible to drag:
- a Table Row to Variable node,
- a Variable to Table Row node, or
- a String Manipulation (Variable) node
… to replace any node that has a single Data input and a single Data output port, e.g. the Row Filter (and vice versa).
While this might be desired behavior when the node being replaced has no connections, it can be disturbing in cases where the node already was fully connected in some workflow context.
Of course you can argue the every node has flow variable ports and therefore your second case holds true, but I’d suggest to distinguish between ports that have connections (that shouldn’t get lost) and any unconnected ports here.
Ok - i see what you mean. I’ll definitely open an issue for the first case once i verify it locally.
For the second case (the one you clarified,) i’ve just re-read through our notes from roughly this time last year when we were working on the ‘drop existing canvas nodes on to other nodes to replace them’ and there is a long storied debate starting with the original ‘replace by drop from repository’ concerning what is “correct” port matching behavior. I’ll dig more into this and bring up your points - thanks for your input!
You can always use Ctrl+Z to undo a drop and restore the connections.
Sure. My critique was merely a suggestion to improve the user experience here. As far as I understood from @quaeler, the current behavior is meant to only allow node replacement when at least one compatible port is kept. In the case I mentioned, this behavior extends to the (hidden) flow variable ports that every node has, and therefore leads to an non-intuitive user experience, IMHO.
But if that has been discussed extensively elsewhere, I’m fine living with the current behavior.
(I was able to verify the first issue locally, both with nodes from the repository and with nodes already on the workflow canvas and opened an issue for this (AP-11772). Thanks again for the report.)
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.