|
|
set CDTVar(attributes) {
{attribute_1 {
{validOperations {operation1 operation2 ...}}
{validFilters {filter1 filter2 ...}}
{dataType {dataType}}}
{attribute_2 {
{validOperations {operation1 operation2 ...}}
{validFilters {filter1 filter2 ...}}
{dataType {dataType}}}
.
.
.
}
These describe each attribute that can be accessed by this class. The fields
in the attributes keyed list are indexed by their attribute name, and
defined in the following way. The validOperations is list of all the
operations (besides create) which are allowed to work on
this attribute. create is always allowed to work on any
attribute (have that attribute
include in the command line passed from the client).
The validFilters is
a list of all the valid filter operations that are allowed to reference this
attribute. The dataType has a value of either
single or set,
which describes the type of data that the attribute contains.
set CDTVar(groups) {
{group_1 {{associatedAttributes {attribute_1 attribute_2}}}}
{group_2 {{associatedAttributes {attribute_2 attribute_3}}}}
.
.
.
}
These described the all the attribute groups that can be accessed by users of
the class being bound. Any of the attributes listed in the
CDTVar(attributes) table can be grouped together
and referenced as
one for convince sake. Only the Get and Replace-with-default
actions can work on grouped attributes. The list is keyed by the name of the
group attributes, and each field contains the
associatedAttributes keyed element, which is
a list of attributes found
in the attribute table which the SCOadmin services library will substitute the
group name for before calling any OSA functions.
set CDTVar(operations) {
{operation_1 {
{function {function_1}}
{granularity {perAttribute}}}
}
{operation_1 {
{function {function_2}}
{granularity {perObject}}}
}
.
.
.
}
This table defines all the operations that users of the class can call on.
The operation list is keyed by the name of the operations themselves. Each
operation key contains a sub-list composed of two keyed elements;
what Tcl function the
SCOadmin services library
should call when the operation is to be performed, function,
and in what synchronization the procedure should be called,
granularity.
The granularity of a function call can only be one of two values;
perAttribute or perObject.
Although the OFBinding routine will only look for these four fields (attributes, groups, operations & class name), the OSA writer can place extra data in the CDT without concern about the Server API reporting errors. This is useful for OSA writers who need to store extra information about the class (such as contained sub-classes) in some common place.
The OFBinding routine also allows the OSA to specify a request processor to handle incoming BMIP requests. If the OSA needs to perform such specialized functions as containment, synchronization, scoping or first pass validation; then it should provide a request processor and point to its location with this parameter. The request processor is explained in more detail in the SCOadmin Developer's Guide.
The OFBinding routine also allows the OSA to attach a data string with every declared class. This string can contain anything, and is often best used as a handle to class specific information, thus a useful way for multiple classes that are identical in function but not in data to be created. This can by done by calling OFBinding once for each class, with the osaDataPtr variable naming a different data storage area for each class instance. This variable is never examined by the SCOadmin services library, and is forwarded to all functions in the OSA called by the library.