Extending Association Behavior in QtView Classes

Simulation Modeling Toolkit (SMTK)
1

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.

2

@chart3388 @amuhsin @dcthomp @johnt @tj.corona - feel free to comment!

3

With association logic that is outside smtk, I would expect that we will also need to support an external validation function for associations.

I presume this isn’t the feedback you are looking for, but the example seems asymmetric. It seems like the “AdditionalAssociationTest” would be more suitably named “AssociationTest”, with the name indicating that the logic replaces the default association test, in lieu of augmenting it.

In fact, I would consider using a prefix like “External” to indicate any such options that are outside smtk. So in this case, e.g., “ExternalAssociationTest”, “ExternalDisassociationTest”, “ExternalAssociationsValid”.

As for the 2 implementations, I don’t have any alternatives to suggest, but the topic seems to imply that the 2 approaches are mutually exclusive. We could support both formats (maybe call them “InlineAssociationTest” and “ExternalAssociationTest”) if we are willing to check that somebody didn’t specify both types for the same attribute.

Specific to the first option (embedding source code):

  • I am not a big fan of putting code inside an xml document, but if we support it, I would use a CDATA section. Otherwise you will have to replace markup characters (<, >, &, ', ") with character entiies (&lt;, &amp;, &rt;, &apos;, &quot;) in the source.

For the second option (specifying a function name in an xml attribute)

  • I would recommend using a fully-qualified function name. So if the function foo is in a source file functions.py in the same directory as the .sbt file, the xml attribute would be AdditionalAssociationCheck="functions.foo".
4

I agree that mixing the python code with the xml wouldn’t be the cleanest approach.

I also agree that the second option would be more attractive if we can reference code that’s in a separate python file in the SBT directory instead of a plugin.

Storing the python code in a plugin will only allow us to support one version at a time since storing multiple versions of the python code in a plugin would be tedious.