You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current it is required to explicitly create a parameter for each workflow input that is to be displayed in a widget. We should explore if we can fall back to auto-generating this. This would make the widget usable with less need for customization, at least for basic parameter types.
The approach would likely require inspecting the type of the workflow input, which can map to a corresponding parameter type. This will work fine for basics such as int, float, str, bool, etc., but not for types that alias some generic containers such as scipp.Variable.
I think it is probably useful to implement this anyway: Even if the solution does not work in all cases it will nevertheless reduce the need for boilerplate code (both in our own technique packages as well as for users writing their own workflows).
The text was updated successfully, but these errors were encountered:
Current it is required to explicitly create a parameter for each workflow input that is to be displayed in a widget. We should explore if we can fall back to auto-generating this. This would make the widget usable with less need for customization, at least for basic parameter types.
The approach would likely require inspecting the type of the workflow input, which can map to a corresponding parameter type. This will work fine for basics such as
int
,float
,str
,bool
, etc., but not for types that alias some generic containers such asscipp.Variable
.I think it is probably useful to implement this anyway: Even if the solution does not work in all cases it will nevertheless reduce the need for boilerplate code (both in our own technique packages as well as for users writing their own workflows).
The text was updated successfully, but these errors were encountered: