When categories where first implemented, their role was to provide a way of filtering the information within an Attribute Resource but they did not change the actual state of the Resource.
Though categories have been expanded in terms of information modeling (such as adding categories to discrete item’s enums) and functionality (such as determining the validity of an Attribute or Item), they still do not effect that actual data state of the Attribute Resource.
Recently, developers/designers have requested features that may require categories to actually change the state of the Resource.
Default Values Based on Categories
Designers would like the ability to associate category constraints to an Item’s default value. For example an Integer Item foo could have the following defaults:
- 1- If the Heat Transfer Category is preset
- 10 - If the Heat Transfer and CFD Categories are present
Possible design and implementation for this would be discussed in a different discourse.
Reference Items Behavior Issue
Lets assume that we have two Reference Items that share the same role (meaning that a persistent object can only be assigned to one of the items):
- foo - Belongs to category a
- bar - Belongs to category !a
Lets also assume that category a is present and model face f1 is assigned to foo. The user then switches category a off resulting in foo being hidden and bar being displayed. The user will not be able to assign f1 to bar since its still assigned to foo.
What should probably happen is foo “loses” ownership of f1 when a is turned off but might reacquires f1 (potentially) if a is turned on again.
##Expanding Category’s Role
So in order to support the above feature requests, the set of relevant categories would need to be available to functions such as setting and getting values of Items which could be very tedious and error prone.
The proposed solution would be to set the collection of “active” categories on the attribute Resource which would then be used by Attributes and Items. For example, the Attribute Resource’s active category information could be used to:
- Attribute::isValid/Item::isValid
- Getting the value of an item using a default
- Assigning discrete value that is category dependent
- Assigning Persistent Objects to Reference Items using roles (including Attribute’s associations)
Proposed API
- const std::set<std::string> & attribute::Resource::activeCategories()
- void attribute::Resource::setActiveCategories(const std::set<std::string> &)
- All isValid methods that do not specify a set of categories will now take in a bool to indicate if it should be using the resource’s active categories or not (default would be true)
- Active categories would be saved in the Resource’s .smtk file.
Another Benefit
Currently most of the category filtering code is in SMTK’s Qt layer. The above changes would in theory move most of the logic into the core attribute system, reducing the code in the Qt layer. This would make developing Web-interfaces easier since they would not need to duplicate the code in the Qt layer.