Modelling attributes

Attributes as a concept is explained in Attributes.

This page explains how to model attributes based on real-world examples.

Let's start by defining a few prerequisites.

Prerequisites

Global lists act as a data source on a field level. This means that field values can be bound to centrally managed global lists.

Here are a few examples of what global lists might be used for.

Horizontal resolutions

Vertical resolutions

Units

Weekday numbers

1=Monday, 2=Tuesday, etc.

Clothing materials

Splashes

Examples

TV_SCREEN_RESOLUTION

Suppose we want an attribute to describe a tv screen resolution. We need to be able to store horizontal and vertical resolution individually, and further we want to be able to store a name too. The horizontal and vertical resolutions must be bound to the HORIZONTAL_RESOLUTIONS and VERTICAL_RESOLUTIONS global lists. The name should be a text.

For this we can choose the Unconstrained configuration which will allow us to do so with proper field configurations.

For each tv it should only be possible to store a single value, and we want to bind to a set of predefined values for users to choose from.

The configuration for this attribute is:

• Name: TV_SCREEN_RESOLUTION
• Type: Single valued
• Configuration: Unconstrained
  • Field1: Type: PInt32, Data souce: HORIZONTAL_RESOLUTIONS, Name: HRes
  • Field2: Type: PInt32, Data souce: VERTICAL_RESOLUTIONS, Name: VRes
  • Field3: Type: PString, Name: Name
  • Field4: Not in use

For the attribute, we therefore define the following predefined values.

Predefined value set: (id PDV1)

When adding this attribute to some entity like for example a product catalogue item, the user can only choose from the predefined set of values, and the actual value stored will be PDV1_1, PDV1_2, or PDV1_3 which references the predefined values.

TV_HORIZONTAL_RESOLUTION

Suppose we want to store a horizontal resolution in its own attribute. We want to bind the values to the HORIZONTAL_RESOLUTIONS global list. Since there's only one field in use, there's no need for predefined values. We simply rely on field level binding.

For this we can choose the Plain configuration which gives us a single field to work with.

The configuration for this attribute is:

• Name: TV_HORIZONTAL_RESOLUTION
• Type: Single value
• Configuration: Plain
  • Field1: Type: PInt32, Data source: HORIZONTAL_RESOLUTIONS, Name: HRes
  • Field2: Not in use
  • Field3: Not in use
  • Field4: Not in use

When adding this attribute to some entity like for example a product catalogue item, the user will be asked to assign a value for field 1, and since that's bound to HORIZONTAL_RESOLUTIONS, it's only possible to choose a value that exists in the HORIZONTAL_RESOLUTIONS global list.

So, why don't we define predefined values for this attribute?

Predefined values make most sense when either:

1. The attribute has more than one field (because they make it possible to create predefined combinations of the fields that are valid for the attribute)
2. You want to limit or filter the items in a global list such that only a subset of the items are valid for the attribute

Neither of the two apply in this example, so it is not necessary to define any predefined values.

LONG_DESCRIPTION

Suppose we want to store a long description on product catalogue items. It should not be translatable, and users should be able to write whetever they want on each product.

For this we can choose the Plain configuration which gives us a single field to work with.

The configuration for this attribute is:

• Name: LONG_DESCRIPTION
• Type: Single value
• Configuration: Plain
  • Field1: Type: PString, Name: Long description
  • Field2: Not in use
  • Field3: Not in use
  • Field4: Not in use

When adding this attribute to some entity like for example a product catalogue item, the user will be asked to assign a value for field 1, and since it doesn't have a data source, the user is free to enter any free text.

INNER_VOLUME

Suppose we want to store a volume which consists of height, width and length, and further that the volume must be specified in a cubic meters (m³). Height, width and length must be decimal numbers with two digits behind the decimal separator.

For this we can choose the Cuboid volume configuration which allows us to do so with proper field configuration.

The configuration for this attribute is:

• Name: INNER_VOLUME
• Type: Single valued
• Configuration: Cuboid volume
  • Field1: Type: PDecimal2, Name: Height
  • Field2: Type: PDecimal2, Name: Width
  • Field3: Type: PDecimal2, Name: Length
  • Field4: Not in use
  • Unit: Data source: UNITS, Chosen item: UNITS_2

When adding this attribute to some entity like for example a product catalogue item, the user will be asked to assign values for fields 1, 2, and 3, and it will be implied that the numbers are m³ due to the unit specification in the configuration. For all fields, the user will be allowed to enter any decimal number with 2 digits behind the decimal separator due to the choice of type PDecimal2.

SURFACE_AREA

Suppose we want to store an area which consists of height and width and further that the volume must be specified in a square meters (m²). Height and width must be decimal numbers with two digits behind the decimal separator.

For this we can choose the Rectangular area configuration which allows us to do so with proper field configuration.

The configuration for this attribute is:

• Name: SURFACE_AREA
• Type: Single valued
• Configuration: Rectangular area
  • Field1: Type: PDecimal2, Name: Height
  • Field2: Type: PDecimal2, Name: Width
  • Field3: Not in use
  • Field4: Not in use
  • Unit: Data source: UNITS, Chosen item: UNITS_1

When adding this attribute to some entity like for example a product catalogue item, the user will be asked to assign values for fields 1 and 2, and it will be implied that the numbers are m² due to the unit specification in the configuration. For all fields, the user will be allowed to enter any decimal number with 2 digits behind the decimal separator due to the choice of type PDecimal2.

WORKING_DAYS

Suppose we want to store an interval of working days from one week day to another. We want to bind the values to the WEEKDAY_NUMBERS global list. For simplicity let's say that all possible combinations of from and to values are valid, we don't need to specify predefined values. We simply rely on field level binding.

For this we can choose the Range configuration which allows us to do so with proper field configuration.

The configuration for this attribute is:

• Name: WORKING_DAYS
• Type: Single valued
• Configuration: Range
  • Field1: Type: PInt32, Data source: WEEKDAY_NUMBERS, Name: From
  • Field2: Type: PInt32, Data source: WEEKDAY_NUMBERS, Name: To
  • Field3: Not in use
  • Field4: Not in use

When adding this attribute to some entity like for example a product catalogue item, the user will be asked to assign a value for fields 1 and 2, and since they are both bound to WEEKDAY_NUMBERS, it's only possible to choose values that exist in the WEEKDAY_NUMBERS global list.

For simplicity we decided that all combinations of From and To are valid. If that's not acceptable and we instead wanted to restrict the possible combinations to say "monday (1) to friday (5)" and "saturday (6) to sunday (7)" just to name two examples, we could define predefined values as follows:

Predefined value set: (id PDV2)

PDV2_1 points to a value where From = 1 (monday) and To = 5 (friday), and PDV2_2 points to a value where From = 6 (saturday) and To = 7 (sunday).

So, in this example, we use predefined values to restrict the number of possible field value combinations to only a few, even if the global lists used as field data source have many more values.

MATERIALS

Suppose we want to store information about which materials that a product catalogue item consists of and a corresponding quantity. It must be possible to specify multiple values per product catalogue item. The users should only be allowed to choose between specific materials.

All possible combinations of material and quantity are valid and so we don't need to specify predefined values. We simply rely on field level binding in combination with free unbound fields.

For this we can choose the Quantified configuration which allows us to do so with proper field configuration.

The configuration for this attribute is:

• Name: MATERIALS
• Type: Multi valued
• Configuration: Quantified
  • Field1: Type: PPString, Data source: CLOTHING_MATERIALS, Name: Item
  • Field2: Type: PDecimal2, Name:Quantity
  • Field3: Not in use
  • Field4: Not in use

When adding this attribute to some entity like for example a product catalogue item, the user will be asked to assign values for fields 1 and 2. For field 1, since that's bound to CLOTHING_MATERIALS, it's only possible to choose a value that exists in the CLOTHING_MATERIALS global list. For field 2, the user will be allowed to enter any decimal number with 2 digits behind the decimal separator due to the choice of type PDecimal2.

IMAGES

Suppose we want to be able to store a list of images along with a translated alt text on a product catalogue item. The image is a MediaBank image, so we need a way to reference it. Since the attribute system is built on top of the PIM data types, we can take advantage of the referential data type PMediaBank6File.

For this we can choose the Unconstrained configuration which allows us to implement the attribute with proper field configuration.

The configuration for this attribute is:

• Name: IMAGES
• Type: Multi valued
• Configuration: Unconstrained
  • Field1: Type: PMediaBank6File, Name: Image
  • Field2: Type: PTranslatedStringD, Name: Alt text
  • Field3: Not in use
  • Field4: Not in use

The configuration introduces some new concepts. Referential types (PMediaBank6File) and segmented types (PTranslatedStringD). PMediaBank6FileLink is a value that is actually a pointer to some file in mediabank. PTranslatedStringD is a PString wrapped in a data type which is segmented on Translation Culture and in case no matching culture is found, it defaults (denoted by the "D" suffix) to some default value.

When using referential types, PIM will show a chooser or searcher to allow the user to set a value in the field without manually entering the reference. In the MediaBank case, a file chooser is displayed.

When using segmented types, PIM allows the user to set individual values for each segment (here translation culture), so for example, a Danish, English, and German alt text can be entered along with a default value.

SPLASH_IMAGE

Suppose we want to be able to diplay an optional splash image (for example a discount splash) on products in the frontend. The splashes are identified by a name that is defined in the SPLASHES global list and an image.

For this we can choose the Unconstrained configuration which allows us to implement the attribute with proper field configuration.

The configuration for this attribute is:

• Name: SPLASH_IMAGE
• Type: Single valued
• Configuration: Unconstrained
  • Field1: Type: PString, Data source: SPLASHES, Name: Splash
  • Field2: Type: PMediaBank6File, Name: Image
  • Field3: Not in use
  • Field4: Not in use

This will allow defining a single splash on an entity like for example a product catalogue item which the frontend can place on top of the product image thumbnail(s).