Warning: The implementation of this pattern has been discontinued and removed since
GeneXus 17 Upgrade 5. Sources are available at https://github.com/genexuslabs/category-pattern.
The name 'Category' is self-descriptive, as this pattern is used to 'categorize' items.
See the Difference between Type and Category.
When you have a set of things, it's very convenient to gather them in groups or 'categories'. Most of the time this is quite simple, just adding a Category transaction to the model is enough:
Category
CategoryId*
CategoryName
Item
ItemId*
ItemName
CategoryId
CategoryName
However, sometimes more advanced features are necessary:
- An Item can belong to many categories (not just one as in the example above).
- Validity. An Item belongs to a certain category only during a certain period of time.
- Hierarchy of Categories. Instead of a set of 'flat' Categories, a hierarchy (such as Beverage (Alcoholic Beverages (Wines, Beers)), etc.) is needed.
- Many Categories. You can have a set of categories to group Products from an Accounting point of view and another set to group them from a Production point of view.
The purpose of this pattern is to provide all the objects needed to implement a 'high-end' Category engine for a given transaction.
This pattern is very useful for building Product Catalogs.
Beverages
Alcoholic Beverages
Wines
Red
'Wine xxxx' (item)
'Wine yyy' (item)
...
Beer
Light
'Beer 123' (item)
...
This kind of catalog usually has a validity period, and you can have more than one Catalog at once.
For the generation of the default instance, you must have an Item transaction:
Supposing the pattern is applied to an Item transaction (above), then the new transactions that this pattern generates by default will be as follows:
- Each ItemCatId with ItemCatParentId null is the root of a 'Catalog' (a category tree).
- In this simple model no Validity functionality is provided.
Functionality needed:
- Hierarchy data entering for categories.
- Copying of categories.
- User-friendly Category/Item relationship assignment (probably using Multiple Values Assignment Pattern).
- Category deleting (which entails deleting all its children and all the Category/Item relationships).
The Instance has the following nodes:
- AttributesName. Name of the attributes for CategoryItem transaction: ItemCatId, ItemCatName, ItemCatParentId (subtype of ItemCatId) and ItemCatParentName (subtype of ItemCatName).
- Transaction Names. CategoryItem and CategoryItemrelation.
By default this pattern generates the following objects:
- CategoryItem Transaction - Defines Category Hierarchy. Each Category with null CategoryParentId is the root.
- CategoryItemRelation Transaction - Defines the relationship between Items and Category.
- TreeViewCategoryItemRelation Web Panel - Displays a Tree View of each category with its assigned items (see TreeView Sample below).
- ItemCatalog Data Provider - Implemented to load the Tree View from the Start event of the TreeViewCategoryItemRelation Web Panel.
- ItemByCategoryItemWC Web Component - This Web Component displays the Items assigned to a category from the TreeViewCategoryItemRelation Web Panel (see TreeView Sample below).
- CategoryItemRelationWC Web Component and AddItem and DeleteItem Procedures - Allows you to add items to a category or delete them from a category.
The picture below shows the full node:
From the TreeView Web Panel you can not only obtain views but also assign items to categories. The following picture shows what happens after selecting the Salads node.
Clicking on Assign Items To Salads takes you to the situation shown in the picture below. Here, the back and forward buttons allow you to move elements from one side to the other for the Salads category.
See also Setting the Category Pattern to know the general settings related to all instances.
This Pattern features the use of the Treeview User contol in order to render the folder and category view on screen.