Introduction

The "Items with features" view and its siblings "Products with features" and "Variants with features" views show all items/variants/products of a structure group and display their attributes in the context of the structure group features. This means values will be converted in the datatype and unit of the structure group feature.

The old implementation of this view had some flaws due to its origin as a customer solution:

• In the old view the decision whether an attribute is mapped to a feature has been done via the name. This could lead to free attributes being displayed in the view and other mapped attributes not being displayed because the name of the attribute was not the same as the name of the feature it was mapped to. In the new view the mapping is done through the AASGAM.

• The old view would not work in a revision, the new one does.

We also added some new features to the view:

• The field selection dialog lets you choose additional fields of the item/variant/product. These will be displayed to the left of the feature columns. In contrast to the feature columns, you can reorder and remove them by dragging them.

• A second language for all feature value columns can be selected which will double the feature columns.

• A header language can be selected. This will change the label in the column header of the feature columns.

• An additional feature column filter has been added. By default, the number of columns is not limited but the number of displayed features is limited. This means if 10 features are configured you get 10 columns for the first language, 10 columns for the second language (if selected) plus additional second value columns in one or two languages for all features with datatype "range". At most you get 40 columns. You can adjust the number of features in the plugin_customization.ini as shown below.
  The feature columns are ordered by the value of the features' field "sequence", not alphabetically. If there are more features than the preference says, those with the highest sequence numbers won't be displayed. If you need to edit them, use the feature column filter.

  preference max.feature.count in plugin_customization.ini

  # Defines the maximum count of features displayed in the items with features (specialized) view. If you

  # increase this number be sure that your view still works correctely. There is a limitation on the character count

  # of all column headers of about 3000. If you exceed this limit it could be that the table will not be displayed

  # properly.

  # com.heiler.ppm.article.structure.core/max.feature.count = 50

Also good to know are these points:

• When grouping or sorting, only the item/variant/product columns (sometimes called static columns) are taken into consideration.
  Also when saving the layout only the item/variant/product columns, the selected languages and the feature filter configuration are saved. The feature columns will not be saved in the layout because they are context dependant and most likely a different structure group will be selected when you open a layout.

• The initial first language (in an empty workspace) is the client language. No second language and no header language is selected.

• You need the article read action right to right see and open the view and the field rights for ArticleAttributeValue.Value and ArticleAttributeValue.SecondValue to see and edit attribute values.

The view

This is an overview of the view implementation. These are the core objects of the view and their interaction will be briefly described below. However, there are many many details which can't be described here.

ArticlesInFeatureContextTableView

• creates FeaturesManager, FeatureFilterManager and FeatureLanguageManager and registers as listener

• when notified by the FeatureManager that features have changed, it asks the FeatureFieldFactory to generate the featureFields, sets them in the tableContainer and fires columnsChanged

• when notified by the FeatureLanguageManager of a

  • new content language:

    • asks the FeatureFieldFactory to generate the featureFields, sets them in the tableContainer and fires columnsChanged

    • updates the table layout config for being able to restore the view later

  • new header language:

    • updates the headers of the columns using the FeatureFieldNameFactory which asks the FeatureLanguageManager for the current headerLanguage.

    • updates the table layout config for being able to restore the view later

• when notified by the FeatureFilterManager that the filter settings changed, it is only stored in the table layout.

  • The columns (and content) are adjusted by the notification of the FeatureManager

FeatureManager

• knows about the structureGroup context

• knows about the preference indicating the number of features

• manages the list of features which is updated when

  • the filter changed (= when notified by the FeatureFilterManager)

  • when the structureGroup context changed

FeatureFilterManager

• contains the filter model (containing the settings) which is manipulated by the FeatureFilterDialog directly. When confirming the dialog with OK, it fires filterChanged().

FeatureLanguageManager

• manages primary, secondary and header language

• notifies its listeners when one of the content languages or the header language is changed

• can persist its settings

Data Access and fragments

The old implementation of the view mapped attributes and features via their name which might be wrong. An attribute can have the same name as a feature but no mapping to it and the other way around, they can have different names but the attribute has a mapping to the feature.

So the right way to load data for the view is to go over the AASGAM. This wasn't possible. In the view we want to get all attributes mapped to the structureGroupAttributes of a specific structureGroup. When loading a listModel with attributes, you need a fieldPath to the aasgam fields. One of the logical keys of these fieldPaths is the attribute name. However, we don't know the names as they can be different to the structureGroupAttribute names.

Therefore we needed a new fragment. The idea is to ignore the name of the attribute but provide enough additional information to be able to retrieve all attributes mapped to a structureGroupAttribute of a certain structureGroup. In the aasgam entity we only wanted to use proxies, so the combination of structureGroup and structureFeature needed to uniquely identify a mapped attribute. Therfore it is no longer allowed to map two attributes of the same article to the same StructureGroupAttribute.

The new fragments of type ArticleAttributeSGContextFragment are contributed in com.heiler.ppm.article.structure.server. They are HQLFragments and use contributed Parameter and ParameterBuilder which replace the generic HQL generation for the ArticleAttribute.LK.Name with our own implementation which takes the given StructureGroup and StructureAttribute from the FieldPath and adds a condition which matches these values against the AASGAM.StructureGroupId and AASGAM.StructureAttributeId of the Attribute.

There are four contributions by intent because there are cases in which you wouldn't get data because of the join condition, if handled by one fragment instance. For example you wouldn't get a value for english if there is no name in english. With the AASGAM fragment there is a different problem. The AASGAM has two parents, the ArticleAttribute and the ArticleStructureMap. It is undefined which parent is used by the fragment, so sometimes it would use ArticleAttribute and because we don't know the attribute name, the resulting data wasn't correct/values were missing.

Displayed values and read validations

The Attribute has three values, the first value, the second value and the different default value, but we only have at most two columns for each feature. This leads to the question which value is displayed?

• If a different default value is available, the different default value will be displayed

• If no different default value is available, the value for identifier "Default" will be displayed. In short: This view only displayes values with identifier "Default" even if the attribute is multivalue and has multiple values.

• If the datatype of the feature is range always the first and second value should be displayed, never the different default value.

Writing

The diagram below shows which value will be written, the ArticleAttribute.Value or the ArticleAttributeStructureGroupAttributeMap.DomainValue.
If a value is entered in the column of a second value (if available), it is written to ArticleAttributeValue.SecondValue. If the attribute has another datatype than "range", the value isn't written at all.

When a value is edited, it is edited in the context of the structureGroupAttribute, so it is first converted in the datatype of the feature, then converted into the attributes unit and then converted to the datatype of the attribute.

Questions and Answers

• Why do I need the Article edit right to see the view?
  Actually you only need the Article read right to see the view.

• Why can't I reorder and remove the feature columns?
  The features are ordered by their order number and can be filtered additionally. Reordering or removing feature columns would not be saved and so get lost if another structure group was selected or the current structure group was changed. This makes it nearly useless.

• Are there similar read validations for detail models?
  Not yet! Perhaps we will add such validations when we refactor other views like the ArticleAttributeTableView (and don't merge it with the Article Attributes cumulative View which would change the data access to listModel loading).