... | ... | @@ -20,7 +20,30 @@ When the time came to be represent the association process, it was decided to us |
|
|
However, the Model Entity Item (in order to be used for modeling associations) behaves differently from all other Items and can cause problems. When you append a model entity to this item it first looks to see if there are any available "slots" in the vector to store it before it tries to append.
|
|
|
|
|
|
To demonstrate this consider 2 items (an int item (I) and a model entity item (M). Lets assume both are of length 4 and they can are extensible. Also assume they have no defaults so all 4 values are unset. If I call append on I, the result is an item of 5 values with the first 4 not set. If I do something similar to M I get an item with 4 values (first value is now set and the remaining 3 are not).
|
|
|
|
|
|
In order to model the set behavior requirement for associations, the item's behavior has to differ in another important aspect - it can't insert the same model entity more than once!
|
|
|
|
|
|
## Proposed Solution |
|
|
\ No newline at end of file |
|
|
## Proposed Solution
|
|
|
|
|
|
I propose that we create a new class to deal with model associations that provides the desired set behavior. Its interface would consist of:
|
|
|
|
|
|
* isValid()
|
|
|
* numberOfValues() (or size())
|
|
|
* requiredNumberOfValues() (or minSize())
|
|
|
* maxNumberOfValues() (or maxSize())
|
|
|
* isExtensible()
|
|
|
* empty()
|
|
|
* insert(...)
|
|
|
* remove(...)
|
|
|
* has (...)
|
|
|
* begin() and end() const iterators
|
|
|
* getAsVector() - returns the set as a vector
|
|
|
|
|
|
We could simplify things further by just returning the underlying set as a const reference (this would get rid of the interator methods)
|
|
|
|
|
|
In terms of the definition for the association - this could be stored in the Attribute definition explicitly instead of needing its own class
|
|
|
|
|
|
## Possible Extension
|
|
|
|
|
|
OK - so if you agree with the above design, I have a conceptual question. As you know SMTK consists of three resources (meshes, models, attributes). One could suggest that instead of saying an attribute is associated with a model entity, it could be associated with a part of a resource. This would mean you could associated an attribute to part of mesh or even to another attribute. Another suggestion would be to take this even further, that is to save an association is a bi-directional relationship between any two resource components (so a mesh set could be associated with a model entity, or a model entity could be associated with an attribute etc..
|
|
|
|
|
|
I don't want to support something just be complete so I would only entertain this extension iff someone can come up with good use cases showing the need for this. |
|
|
\ No newline at end of file |