|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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 NodeFactory s 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. |
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 DataTable
s (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 DataTable
s 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 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:
MyNodeModel
derived from NodeModel
representing the
model of a node. The MyNodeModel
must implement at least:execute(...)
,
which performs the actual task of the node, invoked during executeNode()
.
It gets the DataTable
s from the inputs of the node
as parameters and must provide DataTable
s for the
outputs of the node as result. configure(...)
,
which provides meta information about the DataTable
s that will be generated during execution - at a
time before execution. Some nodes can provide information upfront about the
structure of the DataTable
s they will create,
either after parameters are set or after they've received information about
the incoming DataTable
s. They should return this
meta information in DataTableSpec
s 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 NodeSettings
object.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 saveInternalSettings(...)
.
After 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.MyNodeFactory
derived from NodeFactory
, that returns
new instances of MyNodeModel
, MyNodeView
, and 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. NodeView
and NodeDialog
are optional (the
factory can return null
), a NodeModel must always be provided.MyNodeFactory.xml
must 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.
DataTable
s with new RowKey
s 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.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |