The development architecture of KNIME

Hi,
I want to have an overview of KNIME to benefit the development, better in the graphical way. But couldn’t find it by looking through the tutorials of https://www.knime.com/developers . It says there is a MVC pattern, but they don’t communicate directly with each other, right???
So components of NodeModel, NodeDialog, NodeFactory, NodeView and NodeSettings, how to they interact?

On the view of development of new nodes

NodeFactory is a factory class which creates the NodeModel, and optional NodeDialog and NodeView(s).

The NodeDialog loads and save settings (normally as subclasses of SettingsModel, e.g. SettingsModelString, SettingsModelIntegerBounded, SettingsModelBoolean etc), and presents the user with configuration options for the node - e.g. column selections, output and processing options etc. NodeDialogs are optional - if there are no user settings, then there is no need for a node dialog!

The NodeModel loads/saves and validates the settings. After closing the dialog, the #configure() method of the NodeModel should check the settings entered by the user make sense, and when the node is first added to the workflow attempt to make sensible guesses e.g. at column selections, where possible. The #execute() method in the NodeModel is responsible for transforming the incoming port(s) if there are any to outgoing ports (again if there are any) according to any settings from the user.

Finally NodeViews are optional. You can have as many as you like. They provide optional views of the data or some other facet of the node execution or output. The actual node output ports have their own views of their data which is provided as part of the PortType implementation, so you shouldn’t need to do anything there.

Hope that helps a bit,

Steve

Hi, Steve,

thanks very much for your reply. It helps!! I still have some asks on it, one hand to make sure that I understand you, the other for new questions. Hope it doesn’t bother.

  1. NodeFactory it is, for me, like an initialization class, or entrance like the public static void main() methods in java??
  2. SettingModels. How are they passed in the other classes?? we give some values to SettingsModel in NodeDialog, NodeModel reads them through NodeSettingsRO?? By using object identification string in NodeModel, like NumericBinnerNodeModel.CFGKEY_NR_OF_BINS, they find them in NodeSettingsRO??

Some codes I found may help explain what I mean…
==============in NodeDialog================
addDialogComponent(new DialogComponentNumber(
_ new SettingsModelIntegerBounded(_
_ NumericBinnerNodeModel.CFGKEY_NR_OF_BINS,_
_ NumericBinnerNodeModel.DEFAULT_NR_OF_BINS,_
_ 1, Integer.MAX_VALUE),_
_ “Number of bins:”, 1));_
================in NodeModel===================_
private final SettingsModelIntegerBounded m_numberOfBins =
_ new SettingsModelIntegerBounded(_
_ NumericBinnerNodeModel.CFGKEY_NR_OF_BINS,_
_ NumericBinnerNodeModel.DEFAULT_NR_OF_BINS,_
_ 1, Integer.MAX_VALUE);_

================in NodeModel ======================
protected void loadValidatedSettingsFrom(final NodeSettingsRO settings)
_ throws InvalidSettingsException {_
_ // loads the values from the settings into the models. It can be safely _
_ // assumed that the settings are validated by the method below_
_ m_numberOfBins.loadSettingsFrom(settings);_
_ m_column.loadSettingsFrom(settings);_

_ }_

To set values of m_numberOfBins in NodeModel, they give one unique identification string NumericBinnerNodeModel.CFGKEY_NR_OF_BINS, to the object in NodeModel and NodeDialog, to read and write from NodeSettingsRO or NodeSettingsWO…
Yet, how to really find them, it is out of programmers’ control, since it’s already decided by the KNIME platform?

  1. what if we write our own SettingsModel**** object, the connection between NodeDialog and NodeModel is still automatically built??

Best Regards
Kefang

Hi @KFDing,

  1. The NodeFactory class tells KNIME AP how to create instances of your node.
  2. The SettingsModels give you easy access to the settings.xml file that is associated with each node and stores the actual settings. You can view that if you take a look at a saved workflow with your file explorer.
  • NodeSettingsRO is an decorator interface that prevents your from accidentally writing to the node settings in the read settings method.
  • The settings keys, such as NumericBinnerNodeModel.CFGKEY_NR_OF_BINS are indeed keys into the node settings.
  1. Yes, just make sure to extend the abstract SettingsModel class

best,
Gabriel

1 Like

Hi, @gab1one,

thanks for the reply, especially the part about setting.xml files. Now I think I could at least know how to connection them together.

1 Like

I was just about to reply and saw @gab1one’s answer, which pretty much covers it. I would add only a few things:

  1. KNIME creates an instance of your NodeFactory class from the no-argument constructor, which has to be public visibility (e.g. public MyNodeFactory(){....}) - most of the time you dont need to include this in your code as it will be inherited from the parent NodeFactory. Once KNIME has an instance of your NodeFactory, it uses this to create instances of the other classes mentioned as Gabriel described

3 - a. In the node dialog, when you call addDialogComponent(...), the settings model is stored and saved automatically. You then need to do this manually in the NodeModel. It’s essential the the settings model really is identical, otherwise you wont see the values properly - follow the recommendation to ‘use static factory methods’ to create settings models, along with the other detail at https://www.knime.com/developer/example-nodemodel
3 - b. You can also use settings models without any dialog components to save things for next time in the NodeModel alone - e.g. in https://community.knime.org/svn/nodes4knime/trunk/com.vernalis/com.vernalis.knime.chem.speedysmiles/src/com/vernalis/knime/chem/speedysmiles/nodes/manip/abstrct/AbstractSpeedySmilesManipNodeModel.java in the Vernalis community contribution, were a settings model in the node model holds a version number to ensure backwards compatible behaviour
3 - c. ‘Stuff’ you want to save that relates to node execution (for example a data digest for a node view) should be saved via the Node internals in the node model (see https://www.knime.com/saveinternals and https://www.knime.com/loadinternals) - most of the time you wont need to do anything with these though!

Steve

1 Like

Hi @s.roughley

I have began coding in KNIME, and found some concrete questions that I think relate to the architecture. Like those:

  1. How to change the outputSpec according to the model execution result??
    eg. in source node, I can only know the type of object after I read the file[ like .xml to represent the information of customer, somehow] in execution method. But the outputSpec is already created in the configuration methods. In such situation, could we update the value of outputSpec in execution method??

  2. How to set the Dialog component values in second node w.r.t. the first Node execution result?? e.g. first node is source to read data, second is the manipulator or leaner… In the second node Dialog, we need to set one options to choose certain type of customer to use. This information is only available in the inData (for me it is PortObject inData). But could it be possible that Dialog has access to inData or “inDataSpec”?? (I can put types information into the inDataSpec)

  3. Is there any limits about PortSpec or TableSpec, or Dialog options?? I doubt that in the situations above, the creation of a workflow is not possible, because the configuration is not complete…

regards
Kefang

Take a look at the javadoc for the configure method:

  1. You can get the input spec in the dialog pane, either by overriding a loadAdditionalSettingsFrom(..) method (if you are using a DefaultDialogPane), or a loadSettingsFrom(..) method otherwise. They are available either as a DataTableSpec[] or PortObjectSpec[].

  2. I think I answered this already in 1. and 2. if not please ask again :slight_smile:

best,
Gabriel

1 Like

Thanks @gab1one - the other resource worth a look, in addition to the JavaDoc are the developer notes and in particular the Noding Guidelines (which tell you how nodes should behave).

Steve