[Smtk-developers] Associating entities vs adding items

[David Thompson]

Hi all,

> I don't see how this would resolve anything - The simplest solution would be to have a property on the definition indicating the max number of model entities the attribute could be associated with.
> 
> Give me a call and we can discuss this.

Apparently I was able to communicate better over the phone than e-mail. :-) We will use a ModelEntityItemDefinition owned by each Definition to describe possible associations and a ModelEntityItem owned by each corresponding Attribute to store the actual list of associated entities. The API to Attribute for associating entities will stay the same but use these instances underneath the hood to do the work (eliminating duplicate code).

The XML for indicating associations will change from having an XML attribute of AttDef named "Associations" to a child element of AttDef named "Associations". It will be parsed as if it were a ModelEntityItemDefinition. Its absence indicates that attributes are not allowed to have associations of any type. So,

    <AttDef Type="union" BaseType="operator" Associations="m">
      <ItemDefinitions ...>
    </AttDef>

will become

    <AttDef Type="union" BaseType="operator">
      <Associations MembershipMask="m" Extensible="true" NumberOfRequiredItems="1"/>
      <ItemDefinitions ...>
    </AttDef>

A similar change will be made for specifying attribute instances in XML.

By making the ModelEntityItem and ModelEntityItemDefinition instances available from the Attribute and Definition (respectively), the GUI panels can also add UI elements corresponding to associations. This is important for SMTK operators since currently things like the "union" operator do not provide any way to change or set the workpieces to process.

These changes should go in next week some time.

	David


>> Yumin and I were discussing CMBv4 and Yumin mentioned that while attributes can indicate the type of entities they may be associated with, there is no way to describe limits on the number of entities (e.g., a subtract operator may support only a single workpiece at a time, but the GUI cannot infer that too many models are selected for the subtract operator).
>> 
>> One way we might accommodate storing extra information about associations is to ditch the way associations are currently stored and create a special ModelEntityItem that is marked as the attribute's associations. Instead of
>> 
>>  <AttDef ... Associations="m">
>>   <ItemDefinitions>
>>     ...
>>   </ItemDefinition>
>>  </AttDef>
>> 
>> we would have
>> 
>>  <AttDef ... Associations="itemName">
>>   <ItemDefinitions>
>>     <ModelEntity Name="itemName" .../>
>>     ...
>>   </ItemDefinition>
>>  </AttDef>
>> 
>> 
>> 	Any opinions?
>> 	David
>> _______________________________________________
>> Smtk-developers mailing list
>> Smtk-developers at smtk.org
>> http://public.kitware.com/mailman/listinfo/smtk-developers
>