Currently in SMTK’s Attribute System a Definition gets its categories from the following sources:
- Locally defined Category Set
- Category Sets inherited from its Item Definitions
- Category Sets inherited from the Definition it is derived from.
Here is an example:
When the category set information gets processed, we have the following result:
- Definition 1 (A | B | C)
- Item 1 (A | B)
- Item 2 (A | C)
- Definition 2 (A | B | C | D | E | F)
- Item 3 (D | E)
- Item 4 (D | F)
Definition 1 was explicitly told that all of its items should belong to Category Set A by default. It pushed its local Category Set down to its items. The items push their categories back up to its Definition which get combined with its local Category Set plus those it inherited (which in this case is none), resulting in Definition 1 having Category Sets A, B, C.
A similar thing happens to Definition 2, except that in this case it inherited (A | B | C) from Definition 1.
You can play what if and you will see that this makes sense - for example assume I have Attribute A2 which is created from Definition 2. If I have Category Set A active, then A2 is relevant cause Item 1 and Item 2 would pass their category checks.
But what if you wanted inheritance to be more restrictive? For example, say you wanted A2 to be relevant if only Category Set D was active? In the UI, this would mean that Item 1 would be displayed only if (D & (A | B)).
What is being proposed here is to add the ability to turn off inheriting category information from the Base Definition. We already have a mechanism to control this at the Item Definition level via the method setIsOkToInherit. I would add the same method to the Definition API along with isOkToInherit. This information would be persistent and stored in both XML and JSON formats.
Potential Downside
Since this mechanism gives the user the ability to override the category inheritance mechanism, care must be taken to avoid an empty UI from being generated. Consider this variation of the original example:
In this case Definition 2 does not have any items of its own and the goal was to just make those inherited from Definition 1 be more restrictive. If Category Set D is the only one active, then attributes created by Definition 2 will pass their relevancy checks; however, in this case the attributes’ UI will be empty since there are no items that will pass their relevancy checks.