1-to-1 Command: Table input vs. Dialog input

[dietzc]

If we wrap a 1row-to-1row Command into a KNIME node, there are always two possible ways to resolve required input parameters. Example with String input parameter: we can get the String value from the input table (which is then potentially different for each row) or we can enter the value in a dialog component (which is then always the same for each row, given that this dialog component is not controlled by a flow-variable).

There are three situations:

• Example with image: Value can only be resolved from table (for example an image can't be entered in the dialog). In this situation we have to provide a column selection widget which allows us to select which column of the input table contains the images we want (if there is more than one image column). if there is no image column, the node can't be configured.
• Example with color: We can only select the color in a ColorSelection component in the Dialog. Value can't be provided from the table (ok, maybe it can if we represent color as hex, but I think it's obvious what I mean).
• Example with String: Both above mentioned options are possible. Conflict!

If we wrap an arbitrary Command we have to define a strategy to resolve the conflict. Here is what I suggest: If both is possible (selection via table or via dialog) we only provide the possibility to enter the desired value via the dialog component as we can always use flow-variables to loop over the input table if desired and therefore simulate the column binding. This is the KNIME way to do it.

However, if someone writes a Command (for now called SciJavaNode), he should be able to control this behaviour in the code. One suggestion is, that he uses the extra @Attr annotation of the @Parameter of SciJava, to give a hint to the UI generation (simple flag with two states) Additionally, we have to add WidgetModels for the column selection itself.

[imagejan]

I have a question regarding the String use case above:

If both is possible (selection via table or via dialog) we only provide the possibility to enter the desired value via the dialog component as we can always use flow-variables to loop over the input table if desired and therefore simulate the column binding. This is the KNIME way to do it.

For example if you have a table with columns "Image_Title" and "Image", and you want to label each image (e.g. by adding a TextROI and draw the pixels or some such). For this you'd need to access both the String column and the Image column of the current row. Is the "KNIME way to do it" really to use yet another node to get the String flow variable?

[dietzc]

Ok, given we write a "pure" KNIME node with the purpose to process huge amounts of images + text, then the KNIME way to do it would be to collect the data from the table of course. However, if we auto-generate nodes from arbitrary Commands (which we didn't write on our own), we can't decide what to do. So the best we can do is to provide both options, again here are two possibilities:

• Provide both possibilities (Selecting column or entering the value) in the configuration dialog. We have this in our current ImageJ2 integration. However, this is very confusing and not very KNIMEIsh (no KNIME node provides both options).
• Or we stick to "entering the value" only. Doing so, we are always able to simulate a table input via the Flow Variable Loop Start node.

However, with the @Attr we want to provide the flexibility for the developer to decide on his own, if she already knows that she wants to expose her Command as a KNIME node.

Does this make sense?

[imagejan]

Does this make sense?

Alright, yes, that makes sense. Thanks for the clarification!

[gab1one]

So we either have:

• Option A: the default is to show both options and allow developers to only show the relevant one using the @Attr. Maybe a rewritten dialog component can be less confusing for users.
• Option B: we default to "entering value only" and if a Command sets our @Attr we show a column selection instead.

I think option B is easier to get done correctly.

[dietzc]

Option B is the correct one. @Attr allows to toggle or enforce a certain behaviour.

[gab1one]

This would like the following:

@Parameter(attrs={@Attr(name = "useKNIMEColumnSelection", value = "true")})
private int someValueFromColumn;

Needs a better name though.