Internally used interface.
Interface which allows a NodeModel to hold (and keep) internal BufferedDataTables.
Read-only interface for
Object passed to
Implement this interface if you want to get informed about progress change events and if you want to can ask for cancelation.
Interface to generate a set of node factories and, hence, a set of nodes.
Read-only interface for
Interface for export types.
|AbstractNodeView<T extends NodeModel>||
Abstract implementation of a node view.
DataTable implementation that is passed along the KNIME workflow.
|ContextAwareNodeFactory<T extends NodeModel>||
This extension of
A persistor cloning a node's settings.
The default node progress monitor which keep a progress value between 0 and 1, and a progress message.
Silent progress monitor which does only forward changed of the progress value rather than progress message.
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.
An adapter on
|DynamicNodeFactory<T extends NodeModel>||
A node factory to create nodes dynamically.
An empty dialog, which is used to create dialogs with only miscellaneous tabs (such as memory policy and job selector panel).
This node's execution monitor handles the progress and later also memory management for each node model's execution.
(No-API) Core Extension of
Base class for custom buffered data table types.
Various parameters needed for loading an extension table.
|ExternalApplicationNodeView<T extends NodeModel>||
Node view which opens an external application.
Container holding information regarding variables which represent settings of a node and/or are used to replace settings of a node.
Button for a
Helper class to allow also the display of disabled list elements.
Class that hold static values about the KNIME platform.
Event listener that works around bug #5170.
Implements the tab for the memory policy of nodes with output ports.
This ModelContent is used to store XML-like model settings.
Implementation of a node as basic processing unit within the workflow.
Keeps information about incoming connectors (type and name).
Keeps outgoing information (specs, objects, HiLiteHandlers...).
Information object to a node.
This abstract class describes the meta information about a node.
This class is used to parse the XML files with the node description that accompany every node factory.
The standard node dialog used to display the node dialog pane.
The base class for all node dialogs.
|NodeFactory<T extends NodeModel>||
Abstract factory class for all components that make up a node, i.e.
Base class for extension point to allow node vendors to define a
Repository that allows access to all node factories registered at the node extension point.
This class stores a complete list of node triples and their frequencies.
Simple class that holds a node factory name and the corresponding human-readable node name.
The general logger used to write info, warnings, errors , debugging, assert messages, exceptions, and coding problems into the internal Log4J logger.
Abstract class defining a node's configuration and execution (among others).
A dialog that contains a progress bar, a label with a message, and a cancel button.
This class overwrites the general
A triple of nodes (predecessor, node, successor) with a count, i.e.
|NodeView<T extends NodeModel>||
Node view class that displays the view content in an AWT-frame.
This class contains all available to-image-export options for node views.
Convenience model class that make some empty stub implementations of methods that are not used by nodes that are not configurable (e.g.
Enum for all node types.
The logging levels.
Policy on how to behave if the node model settings fails.
This exception is used in the
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.
This exception is thrown if a node dialog cannot be opened for various reasons, e.g.
NodeDialogPanethat must be extended when a new type of node is implemented.
Node, together with the abstract
NodeViewdo most of the infrastructural work that is needed to connect a new node in the workflow.
DataTables (see the
datapackage) 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 .
NodeDialogPaneimplements a controller that sets the parameters in the
NodeModelbefore it can be executed.
NodeSettingsobjects. 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.
NodeModelrepresenting the model of a node. The
MyNodeModelmust implement at least:
execute(...), which performs the actual task of the node, invoked during
executeNode(). It gets the
DataTables from the inputs of the node as parameters and must provide
DataTables for the outputs of the node as result.
configure(...), which provides meta information about the
DataTables that will be generated during execution - at a time before execution. Some nodes can provide information upfront about the structure of the
DataTables they will create, either after parameters are set or after they've received information about the incoming
DataTables. They should return this meta information in
DataTableSpecs as a result of this method. The others just return
null. In addition, this method must indicate whether the model received all settings and is ready to be executed.
saveSettingsTo(...)that will write out the current user settings of the model into a
validateSettings(...)which checks a settings object telling if the settings in there are complete and consistent.
loadValidatedSettings(...)which sets new values in the internal settings of the model from a valid settings object.
reset()that clears out all internal data depending on or derived from any incoming data from predecessors.
saveInternalSettings(...)which must save all internal data derived from the input data (that is basically the data cleared during
reset()) onto disk.
loadInternalSettings(...)that must be able to read back the data written during
loadInternalSettings(...)the model must be in the same state as after execute.
loadInternalSettings(...)is called when loading a workflow to re-establish the state of all nodes before closing the flow.
NodeFactory, that returns new instances of
MyNodeDialog, if implemented. The instances created by one factory must work together and form the Model-View-Controller concept for that particular incarnation of a node.
NodeDialogare optional (the factory can return
null), a NodeModel must always be provided.
MyNodeFactory.xmlmust be created, which contains the description of the node, its functionality, its ports, views, and dialog options. The information will be read from the factory and can be retrieved from there. Please read here for the content and structure of the NodeFactory.xml file.
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.
DataTables with new
RowKeys at their outputs. In the method
NodeModel.getOutHiLiteHandler(int)the model decides for each output port which
HiLiteHandlergoes along with the
DataTableprovided at this output port. The default implementation in the abstract
NodeModeljust passes along the
HiLiteHandlerit 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.
KNIME GmbH, Konstanz, Germany
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.