A SMTK Attribute’s Definition provides a simple mechanism to describe what an attribute (or reference item) can be associated with. But what if you wanted to model complex association constraints specific to your workflow? This aim of this topic is to discuss possible mechanisms to achieve this as well as potential issues related to them.
Injecting Python into the SBT/SMTK File
Since SMTK can provide its own Python interpreter, one possibility would be to allow the View Information (currently stored in the Attribute Resource Template (sbt) or Resource (smtk) file) to include Python functions represented as strings. These strings would be given to the interpreter along with the attribute and component for evaluation.
For example it could look something like the following:
<Views> <View Type="Attribute" Title="Example" Label="A" TopLevel="true"> <AttributeTypes> <Att Type="A"> <AdditionalAssociationTest> Python code that takes in an attribute and component to be associated and returns a boolean indicating if the component could be associated </AdditionalAssociationTest > <DisassociationTest> Python code that takes in an attribute and component to be disassociated and returns a boolean indicating if the component could be disassociated as well as a string indicating the reason in case it can not </DisassociationTest > </Att> </AttributeTypes> </View> </Views>
The benefits of this approach is that it is quick to prototype and no plugins would be required. The biggest drawback would be that this could lead to security issues since “foreign” code is being injected into the system via an ascii file. If we did create an Attribute View class that provide this functionality, the application should at the very least notify the user they are running these types of “Python snippets” and provide a mechanism to turn off this feature.
Registering functions based on the attribute’s type via a Plugin
A safer approach would be to have a plugin register additional association/disassociation test functions and then have the AttributeView provide a way to refer to them.
<Views> <View Type="Attribute" Title="Example" Label="A" TopLevel="true"> <AttributeTypes> <Att Type="A" AdditionalAssociationCheck="foo" DisassociationCheck="bar"/> </AttributeTypes> </View> </Views>
In this case there is no foreign code injected in the ascii files.