Lightweight nodes and/or change visual appearance

Node Development
1

A Knime node is quite a heavyweight thing: multiple files, lots of code. This works if the node does something complicated with lots of options, but not so much for small simple atomic nodes. Think of nodes for arithmetic operations: + - / * as an example. Mine are for the relational algebra, and there are about 20 of them, most with few or no options.

Is there a way to produce (say) several little nodes from one plugin, or one node that can change its visual appearance according to which option is selected? For example, semijoin and antijoin use different symbols, but the algorithm is nearly identical.I would like them to look different on the workflow, but not at the cost of so much duplicated code.

2

If you mean a plugin which exposes multiple knime nodes sharing a common code base, under the same eclipse project you could:

  • create the plugin activator class (which extends org.eclipse.core.runtime.Plugin abstract class)
  • create a different package name for each node of your plugin (this is advisable)
  • write for each node the factory xml, the necessary NodeFactory, NodeModel, NodeDialog/NodeView… classes (node wizard can be of help here)
  • under the <extension> tag of plugin.xml file, declare the NodeFactory classes of all you nodes

In the same project you can also add the common code used by your nodes.

Fabrizio

3

Hi @dandl,

This is a case where inheritance is very helpful, you could create abstract superclasses eg. AbstractArithmeticNodeModel that define the common behavior and only override what you need to change in the specific implementations. When you make use of functional programming paradigms you could end up with rather succinct code.

best,
Gabriel

2 Likes
4

Hi,
NodeSetFactories might also something for you. They allow you to generate a set of nodes dynamically, without generating all the files you usually have to create for each node.
Kind regards
Alexander

2 Likes
5

Thank you. This is about how far I was able to get on my own.

So far I have 5 Java files (Dialog, Plugin, Factory, Model, View) for each node, plus a few extra for shared code. You’re saying I can share a single Plugin, but that’s still 4 unique files per node. For (say) 20 closely-related nodes, they all have to be generated, manually edited (to remove unwanted code), hooked up to the common code.

That’s upwards of 100 files to be maintained with an enormous amount of duplication. I’m looking for a strategy to reduce that to (say) 20 files or less.

6

Thank you. Yes, I can do all that in organising my algorithmic code. I just don’t see how that helps to reduce the generated boilerplate. You still seem to need an 4 (or 5) explicit named generated files per node, and that’s the bit I want to avoid.

Of am I missing something?

7

Thanks, looks promising.I found the code, but I wasn’t able to find anything that used it.There is a mention in NodeFactoryRepository, but there it says “not yet exposed to the public”.

I’ve read quite a bit of code around how nodes are created, but nothing helpful so far. I’m not sure how far I’ll get without some sample code.

8

Hi,
The Generic Workflow Nodes by OpenMS and SeqAn use it:


Maybe that helps. If not, let me know!
Kind regards
Alexander

2 Likes