 |
xentara-plugin v1.2.1
The Xentara Plugin Framework
|
|
xentara-plugin v1.2.1
The Xentara Plugin Framework
|
A Xentara I/O driver is represented by an object of a custom driver class derived from xentara::io::Driver. The driver object will usually be a member of the plugin object.
The driver object itself does not contain any functionality. Instead, it provides the following meta information about the driver to Xentara:
The driver object must also provide a callback to create the driver environment, which contains the actual functionality.
The actual functionality of a driver is encapsulated is a custom class derived from xentara::io::Driver::Environment. The environment should contain all the global functionality of the driver that is not directly tied to a specific I/O component, I/O point, or I/O batch.
The driver environment provides callbacks to create standalone I/O components and I/O batches. (I/O components and I/O batches that are children of other I/O components are created by the corresponding I/O component object.) See Creating Plugin Element Objects on how plugin elements are created.
Each type of I/O component supported by the driver is represented by an object of a custom I/O component class type derived from xentara::io::ComponentClass. The component class object will usually be a member of the driver object.
The component class object itself does not contain any functionality. Instead, it provides the following meta information about the component type to Xentara:
The actual components themselves are created either by the driver environment, or, in the case of sub components, by the parent component.
The actual functionality of an I/O component is provided by a custom class derived from xentara::io::Component. This class should contain all component specific functionality that is not tied to a specific I/O point or I/O batch.
An I/O component can publish configuration and status attributes. See Publishing Attributes on how to publish attributes in general, and Publishing Config Parameters as Xentara Attributes on how to publish configuration attributes.
Many I/O component publish a configuration attribute containing the device address. This attribute should have the standard name available through xentara::model::Attribute::kAddress. An I/O component can also publish an attribute containing the current error status. This attribute should have the standard name available through xentara::model::Attribute::kError.
A connection based I/O component should publish a task that attempts to reconnect the device if it has been disconnected. See Publishing Tasks on how to publish tasks.
The component must also provide callbacks to create the I/O points, and any supported sub components and I/O batches. See Creating Plugin Element Objects on how plugin elements are created.
Each type of I/O point supported by the driver is represented by an object of a custom I/O point class type derived from xentara::io::IoClass. The I/O point class object will usually be a member of the driver object.
The I/O point class object itself does not contain any functionality. Instead, it provides the following meta information about the I/O point type to Xentara:
The actual I/O points themselves are created by the I/O component they belong to.
The actual functionality of an I/O point is provided by a custom class derived from xentara::io::Io. This class should contain all I/O point specific functionality that is not tied to the I/O component or an I/O batch. Additionally, an I/O point provides the following information to Xentara:
An I/O point that supports the input direction must provide at least three attributes containing information about the I/O points's value. The following attributes must be provided:
An I/O point that only supports the output direction only needs to provide a value attribute with the role xentara::model::Attribute::kValue. Writing to this attribute should write the value to the output. Please note that an I/O that supports both input and output should handle reading and writing the value attribute independently: Writing the value attribute should not automatically update the read value. The read value should always be taken from the underlying device, to give the device the opportunity to reject or modify the value.
An I/O point will usually publish events that signal changes in these attributes. The name of the event should be the same as the name of the attribute. See Publishing Tasks on how to publish events.
An I/O point can also provide additional configuration and status attributes. See Publishing Attributes on how to publish attributes in general, and Publishing Config Parameters as Xentara Attributes on how to publish configuration attributes.
Many I/O point publish a configuration attribute containing the I/O address. This attribute should have the standard name available through xentara::model::Attribute::kAddress. I/O points that support the input direction can also publish an attribute containing the current read error status, and I/O points that support the output direction can publish an attribute containing the last write error. These attribute should have the standard name available through xentara::model::Attribute::kError and xentara::model::Attribute::kWriteError, respectively.
Each type of I/O batch supported by the driver is represented by an object of a custom I/O batch class type derived from xentara::io::IoBatchClass. The I/O batch class object will usually be a member of the driver object.
The I/O batch class object itself does not contain any functionality. Instead, it provides the following meta information about the I/O batch type to Xentara:
The actual I/O batchs themselves are created either by the driver environment, or, in the case of I/O batches belonging to a specific I/O component, by the parent I/O component.
The actual functionality of an I/O batch is provided by a custom class derived from xentara::io::IoBatch. This class should contain all I/O batch specific functionality that is not tied to an I/O component or an I/O batch.
An I/O batch can publish configuration and status attributes. See Publishing Attributes on how to publish attributes in general, and Publishing Config Parameters as Xentara Attributes on how to publish configuration attributes.
Many I/O batches publish an attribute containing the current error status. This attribute should have the standard name available through xentara::model::Attribute::kError.
An I/O batch will usually have to be executed to query the values of the associated I/Os. The I/O batch should publish a task to allow the user to schedule the execution of the batch in an execution pipeline. See Publishing Tasks on how to publish tasks.