We are beginning to see use cases where the designer would like the act of assigning a SMTK Persistent Object to a Reference Item to also attach a Property to the Persistent Object as well.
For example say you have a Reference Item that represent all of the objects that belong to concept “A” so that the act of adding/removing an Object from the Item represented adding/removing the Object from Concept “A”.
In another attribute you wanted to restrict its association to only Objects that belong to Concept “A”.
If a Reference Item was Resource Component, we could simply refer to the Item; unfortunately it is not.
An alternative approach would be to have the qtReferenceItem UI class have an option to assign a specific Property (type and value) to a Persistent Object when it is assigned to the Item and have that Property removed when unassigned.
Since the act of assigning/removing Properties changes the resource the Object belongs to, the class would use an Operation to set/unset the Property as shown below:
If the Persistent Object is itself an Attribute from the same Resource as the ReferenceItem, then the Property could be directly assigned (since the assumption that the Attribute Resource itself is safe to be modified. Instead of the Property Operation being called, a simple Signal Operation would be used to make sure the rest of the UI is up to date.
Setting the Property Mechanism would be done using an ItemView Configuration.
<ItemViews> <View Item="myRef" PropertyType="long" PropertyName="foo" PropertyValue="5" Role="12"/> </ItemViews>
- The Role must be unique if there can be more than one Attributes from the Definition containing the above Reference Item. If the role isn’t unique, then one Reference Item could remove the Property even though the Object is assigned to another.
- The Property also needs to be unique since you could run into a similar problem if two ItemViews used the same Property name and type.
The main issue here is the need to run an Operation. As of today the Attribute API is not operation-based and to have the implementation of ReferenceItem::SetValue(…) to schedule an Operation could have unforeseen consequences. Prior to doing this, it might be better in the long run to make Item a Resource Component and directly refer to the Item instead of using a Property.