|
|
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.