Expanding the Roles of Categories

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.


@chart3388 @johnt @amuhsin - FYI

Two minor comments:

  • The new setCategory() method could be used in conflict with an analysis attribute, but I presume it would be the application’s job to avoid or resolve that.
  • Perhaps this goes without saying: if an attribute resource doesn’t include categories, then the isValid methods wouldn’t apply the (empty) set of active categories.
1 Like

Good Questions/Observations:

Currently the Analysis Configuration Attribute - though it is used by SMTK’s GUI system to control what information is displayed in the GUI, does not get used by the Attribute Resource itself. In the proposed system, the Analysis Configuration Attribute would be used by the GUI to set the Resource’s Active Categories so I don’t think there would be a conflict per se.

If the Attribute Resource does not have any active categories set, I propose that it should work as it does today which would be to ignore category filtering when it comes to validity checking. In terms of default values, no categories would mean either use the default value that was specified without categories (which is what we have currently) or if all defaults are associated with categories, the item would have no default and would be considered unset.

Privacy Notice