4.9 Interfaces and AddIns for Objects ToC Next

4.9.3 AddIn model ToC Previous Next

AddIns associate a feature or feature-set, represented by an ObjectType to the Node (an Object or ObjectType) they are applied to. The Interface model is different than the AddIn model in that it is based on composition. An AddIn is applied to a Node by adding a Reference to the AddIn instance.

There are no restrictions for AddIn ObjectTypes and there is no special supertype for AddIns. To identify instances as an AddIn, the HasAddIn Reference or a subtype shall be used.

The AddIn ObjectType may include the definition of a default BrowseName using the DefaultInstanceBrowseName Property. Instances of such an AddIn should use this default BrowseName. If an AddIn is instantiated multiple times in the same parent, only one instance can have the default BrowseName.

The definition of an AddIn and its use with a default BrowseName is illustrated in Figure 7E.

readme_files/image008.png

Figure 7 E – Example of AddIn with default BrowseName

As already described, an AddIn can be applied on types and instances. The use on an instance is shown in Figure 7F.

readme_files/image009.png

Figure 7 F – Example of AddIn applied to an instance

Clients can detect the implementation of AddIns by passing the HasAddIn Reference as filter to the Browse Service request. If an AddIn has a default BrowseName, Clients can use the TranslateBrowsePathToNodeId Service with the default BrowseName to get the NodeId of an AddIn.

In the example in Figure 7E the relative path “MyFeature/MyPropertyM” with the starting node MD002 can be used to request the NodeId of this Property and the relative path “MyFeature/MyMethodO” can be used for the respective Method.

Add sections 7.19 and 7.20

Previous Next