search

knime-ip / knip-scijava

KNIP - SciJava Commands Plugin
2 stars 3 forks source link

Handling of unknown Input/Output types #51

Open dietzc opened 8 years ago

dietzc commented 8 years ago

During NodeFactory loading:

Use-case 1: Unknown input type When auto-generating nodes from Plugins we have to make sure that all required=true inputs can be either mapped to Widget or mapped to a column in a KNIME table. If an input type can't be mapped, the node can't be created. We should write a warning in the KNIME log. Important: If someone enforces a column selection and we can't find a corresponding KNIME type for the java-type of the input parameter, but there exists a widget, we would't create the node anyway!

Use-case 2: Unknown output type If we can't map an output-type of a Plugin to a KNIME type we can either create a StringCell and fill the contents with toString() or simply ignore this column. @Squareys @hornm any preference? Either way, we have to be transparent what's happening (hint in console, details in log).

Squareys commented 8 years ago

This will be decided during configure, right? With the same reason because of which there is no .toString() converter in the KNIME Converter Framework anymore:

.toString() may be changed by someone else because in a version change or whatnot, and is therefore not consistent, break tests etc. I find just displaying a warning and ignoring the output a lot more sensible. For wrapped-command-nodes I suggest to possibly create a config setting to print a warning, but else just silently ignore the column. The string would not really provide much use anyway, since this would usually be complex objects.

Or: Just fill the entire column with missing cells? :grin:

dietzc commented 8 years ago

After discussion in person: We decided to create MissingCells of StringCell.TYPE with a warning message in the MissingCell that the output couldn't be mapped and the toString().