Data mapping for subworkflow can be done in two inconsistent ways

[poautran]

In GitLab by @loichuder on Nov 15, 2024, 11:41 GMT+1:

While working on #275, I realized that to map data to a subworkflow, we can either:

• Drag a link to the appropriate named input/output handle of the subworkflow node
  

• Change the data mapping of the said link
  

However, the two are inconsistent and not synchronized. To illustrate this, see that in the example image, I set the data mapping target to In0 while the link points to In1. This is confusing since we don't know to which input the output will be sent (In0, In1, both?).

I would propose to remove the named handles from the subworkflow node and keep only the data mapping. This would make subworkflow nodes more similar to regular nodes which is a good thing in my opinion. To elaborate: when using a node in a workflow, we are not really interested to know if it is a task or a subworkflow underneath: this is a detail of implementation IMO.

Thoughts @woutdenolf @LudoBroche ?

Migrated from GitLab: https://gitlab.esrf.fr/workflow/ewoks/ewoksweb/-/issues/282

[poautran]

In GitLab by @axelboc on Nov 18, 2024, 10:40 GMT+1:

Totally agree, it should be consistent and for now that means removing the handles.

Of course, in terms of UI, we discussed in the past that it would be more intuitive to have separate handles for every input/output on every node. This could even complement the existing Data Mapping UI as long as it's all kept in sync. The separate handles could also be an opt-in or opt-out feature, to accommodate more use cases. 🤷

Anyway, for now, I agree with removing the handles. It will likely clean up a lot of code, and I doubt the current code for separate handles on subgraph nodes would help with implementing a generic solution for all nodes that works together with the Data Mapping feature.