Attribute collections

An attribute collection is a group of item or category attributes that is associated or behave the same way in a context. Attribute collections are used for workflow step validation and catalog and hierarchy views.

Overview

Having an attribute collection increases the efficiency of data model management and performance with many attributes (500+). Attribute collections simplify the management of large sets of attributes. Instead of working with an entire attribute group, it is possible to work on a functional subset of attributes. The subset of attributes can create views, tabs, workflows, inheritance rules, and privileges. Associating a subset is more efficient than associating individual attributes.

If an Attribute Collection property is not created for a hierarchy, and the property is set to auto-generated Core Collection, you run into issues. When the hierarchy has a significant number of categories, not all of the categories can display on a single page in the multi-edit user interface because the vertical scroll bar is not displayed. Alternatively, you can use the Up and Down arrows to browse through the list of categories. The work-around is to create an Attribute Collection property and set it to the hierarchy. After this is set, the vertical scroll bar appears.

There are two types of core attributes:
Default core attributes
Default core attributes are system defined attributes that are retrieved and saved for every object. The default core attributes include only the attributes that are critical to making sure that an item is not saved to the database in violation of key rules.
The default core attributes include:
  • The primary key
  • The path attribute (for categories only)
  • Any required attributes (either from a primary or a secondary spec)
For other attributes, it is not possible for the system to determine whether they are needed. Therefore, in some cases, validation rules are run for every item, and those rules must be included in the core attributes. Hence, user-defined core attributes can be added to the total set of core attributes.
User-defined core attributes
User-defined core attributes are required when an attribute needs to be retrieved and saved for every object. These core attributes are defined per container and include attributes that need to be validated or calculated every time an item or category is saved. A set of user-defined core attributes is associated per container. When creating user-defined core attribute collections, include any required attributes that are in secondary specs. For each catalog and category tree, it is possible to associate an attribute collection as the user-defined core attributes.
Note: Keep the number of attributes at a minimum to achieve optimal performance per user-defined core attributes.
In addition to the core attributes, there are also the following types of attributes:
Item attribute and category attribute (entry node)
A property of an item or a category, for example ID, name or price.
  • An item takes its attributes from the attributes (spec nodes) of catalog spec
  • A category takes its attributes from the attributes (spec nodes) of hierarchy spec
Every attribute on an item or category can have a specified value.
Spec attribute (spec node)
A property of a spec. By adding attributes to a spec you can specify what data fields can be stored for:
  • Items from a catalog that uses this spec
  • Categories from a hierarchy that uses this spec
Spec node attribute
A property of a spec node, such as type, minimum and maximum occurrence, minimum length, maximum length, and validation rule. This attribute determines properties of the spec node and decides how the spec node is used as an item attribute or category attribute when data is stored within it.
In the single edit screen:
  • Specs are rendered in the order that is specified in the View (or the Tab if tabbed view).
  • Nodes with a spec are rendered in the order that is specified in the View. Typically, same as the order in the spec definition, but can be overridden for a tab to not use spec ordering).
  • Primary Key node is only rendered if the View or Tab explicitly includes it. This node allows certain tabs to not show primary spec and primary key node if the solution wants so.
  • Primary Key is no longer rendered always as the first node in the primary spec. Instead, it is rendered at the correct location within the primary spec as specified by the spec order (or view or tab order).