Package org.knime.core.node

Contains all classes needed to implement a new node in the workflow.

See:
          Description

Interface Summary
BufferedDataTable.KnowsRowCountTable Internally used interface.
BufferedDataTableHolder Interface which allows a NodeModel to hold (and keep) internal BufferedDataTables.
ModelContentRO Read-only interface for ModelContent objects.
ModelContentWO Write-only ModelContentWO interface.
NodeContentPersistor  
NodeModelWarningListener  
NodePersistor  
NodePostConfigure Object passed to Node.configure(PortObjectSpec[], NodePostConfigure) in order to modify the output specs in case the node is wrapped and its output is modified.
NodeProgressMonitor Implement this interface if you want to get informed about progress change events and if you want to can ask for cancelation.
NodeSettingsRO Read-only interface for NodeSettingsRO objects.
NodeSettingsWO Write-only NodeSettingsWO interface.
NodeViewExport.ExportType Interface for export types.
 

Class Summary
AbstractNodeView<T extends NodeModel> Abstract implementation of a node view.
BufferedDataContainer DataContainer to be used during a NodeModel's execution.
BufferedDataTable DataTable implementation that is passed along the KNIME workflow.
CopyNodePersistor A persistor cloning a node's settings.
DefaultNodeProgressMonitor The default node progress monitor which keep a progress value between 0 and 1, and a progress message.
DefaultNodeProgressMonitor.SilentSubNodeProgressMonitor Silent progress monitor which does only forward changed of the progress value rather than progress message.
DefaultNodeProgressMonitor.SubNodeProgressMonitor Progress monitor that is used by "sub-progresses", it doesn't have the range [0, 1] but only [0, b] where b is user-defined.
EmptyNodeDialogPane An empty dialog, which is used to create dialogs with only miscellaneous tabs (such as memory policy and job selector panel).
ExecutionContext An ExecutionContext provides storage capacities during a NodeModel's execution.
ExecutionMonitor This node's execution monitor handles the progress and later also memory management for each node model's execution.
ExternalApplicationNodeView<T extends NodeModel> Node view which opens an external application.
FlowVariableModel Container holding information regarding variables which represent settings of a node and/or are used to replace settings of a node.
FlowVariableModelButton Button for a FlowVariableModel, launching a dialog which allows to control the settings.
KNIMEConstants Class that hold static values about the KNIME platform.
MiscSettingsTab Implements the tab for the memory policy of nodes with output ports.
ModelContent This ModelContent is used to store XML-like model settings.
Node Implementation of a node as basic processing unit within the workflow.
Node.Input Keeps information about incoming connectors (type and name).
Node.Output Keeps outgoing information (specs, objects, HiLiteHandlers...).
Node.SettingsLoaderAndWriter  
NodeDialog The standard node dialog used to display the node dialog pane.
NodeDialogPane The base class for all node dialogs.
NodeFactory<T extends NodeModel> Interface for NodeFactorys summarizing NodeModel, NodeView, and NodeDialogPane for a specific Node implementation.
NodeLogger The general logger used to write info, warnings, errors , debugging, assert messages, exceptions, and coding problems into the internal Log4J logger.
NodeModel Abstract class defining a node's configuration and execution (among others).
NodePersistorVersion1xx  
NodePersistorVersion200  
NodeProgressMonitorView A dialog that contains a progress bar, a label with a message, and a cancel button.
NodeSettings This class overwrites the general Config object and specializes some method to access NodeSettings object.
NodeView<T extends NodeModel> Node view class that displays the view content in an AWT-frame.
NodeViewExport This class contains all available to-image-export options for node views.
NoSettingsNodeModel Convenience model class that make some empty stub implementations of methods that are not used by nodes that are not configurable (e.g.
 

Enum Summary
Node.LoopRole  
NodeFactory.NodeType Enum for all node types.
NodeLogger.LEVEL The logging levels.
NodePersistor.LoadNodeModelSettingsFailPolicy Policy on how to behave if the node model settings fails.
 

Exception Summary
CanceledExecutionException This exception is used in the ExecutionMonitor when a node's execution has been canceled.
InvalidSettingsException This exception is thrown during load and save settings within the dialog's pane and model to indicate that the parameters set are not valid and can't be applied.
NotConfigurableException This exception is thrown if a node dialog cannot be opened for various reasons, e.g.
 

Package org.knime.core.node Description

Contains all classes needed to implement a new node in the workflow.

It contains all classes that will be instantiated when a new node is plugged into the workflow. And it provides abstract classes NodeModel, NodeView and NodeDialogPane that must be extended when a new type of node is implemented.

Nodes are connected to each other through their ports. Data or models are exchanged over these connections. Nodes implement a certain task, like reading in data, analyzing, displaying, writing out data, etc. The final class Node, together with the abstract NodeModel, NodeDialog, and NodeView do most of the infrastructural work that is needed to connect a new node in the workflow.

Nodes have different states: not executable , executable , or executed . A node is not executable until all ports are connected to predecessor nodes and all required parameters are set (which depends on the task of the specific node model). If a node is executable the execution can be invoked, causing the node to read in the DataTables (see the data package) and models from its inputs, to do what ever it is supposed to do with the data and/or models (again depending on the specific incarnation of the node model), and to provide new DataTables at its output ports. If execution finishes successfully the node is in the state executed .

Nodes should implement the following Model-View-Controller concept. The model computes and stores the content of the node. A view provides a view to the actual state of the model; it doesn't change the model. There could be more than one view, providing different kinds of views onto the model. The controller is the part that modifies the model. In our case there is more than one controller. The NodeDialogPane implements a controller that sets the parameters in the NodeModel before it can be executed.

the intestines of a node

The communication between the dialog and the model is happening through NodeSettings objects. The dialog will read the current settings of the model before opening, and all user settings will be transfered back into the model (as a side effect, you may not store settings for a node model that are not handled by the dialog, because the). For this, the derived dialog and model must implement load and save settings methods, the model will have in addition a validate settings method. The transfer of these objects is implemented in the abstract classes.

Things a new Node implementation (here called MyNode ...) must  provide:

In addition, a node should think about providing a HiLiteHandler. These are independent and separate instances storing the hilite status for each data point in a DataTable. Any (part of a) node can ask a hilite handler for this property of a given row, and it can also register as listener to be notified of any change in the properties of any row. On the other hand each node can set new properties in a handler and can expect these properties to show in all nodes listening.
New hilite handler instances must be created by nodes that create DataTables with new RowKeys at their outputs. In the method NodeModel.getOutHiLiteHandler(int) the model decides for each output port which HiLiteHandler goes along with the DataTable provided at this output port. The default implementation in the abstract NodeModel just passes along the HiLiteHandler it receives at input port "0". If it has no input port, it will instantiate a new HiLiteHandler, as it must be the beginning of a data flow then. There are default hilite handler implementations (see package property) that can be used when a new handler instance is needed.



Copyright, 2003 - 2010. All rights reserved.
University of Konstanz, Germany.
Chair for Bioinformatics and Information Mining, Prof. Dr. Michael R. Berthold.
You may not modify, publish, transmit, transfer or sell, reproduce, create derivative works from, distribute, perform, display, or in any way exploit any of the content, in whole or in part, except as otherwise expressly permitted in writing by the copyright owner or as specified in the license file distributed with this product.