The name is self descriptive in that this pattern is used to categorize items.
See Difference between Type and Category.
When you have a set of elements, it's very convenient to sort 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 needed:
- An Item can belong to many categories (not just one as in the example above).
- Validity. An Item belongs to a certain category only for a period of time.
- Hierarchy of Categories. Instead of a set of 'flat' Categories, a hierarchy (like: Beverage (Alcohol Beverages (Wines, Beers)), etc.) is needed.
- Many Categories. You may have a set of categories to group Products from an Accounting point of view and another set for 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.
Canonical Example
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)
...
Many times this kind of catalogs has a validity period and can have more than one Catalog at once.
Implementation
Assuming that the pattern will apply to an Item transaction, the new transactions are as follows:
Category // defines the category hierarchy
CategoryId*
CategoryName
CategoryFatherId // defines the hierarchy
CategoryFatherName
CategoryItem // defines the Category/Item relationship
CategoryId*
CategoryName
ItemId*
ItemName
Notes
- Each CategoryId with CategoryFatherId null is the root of a 'Catalog' (a category tree).
- In this simple model no Validity functionality is provided.
Functionality needed:
- Hierarchy data entry for categories
- Copying categories
- User-friendly Category/Item relationship assignment (probably using Multiple Values Assignment Pattern )
- Deleting categories (deleting all of its children and all the Category/Item relationships)
Implementation of Category Pattern
For generating the default instance file, you must have an Item transaction:
ItemId*
ItemName
The Instance File has the following nodes:
ItemTransaction - In this case Item Transaction.
AttributesName - Name of the attributes for CategoryItemRelation Transaction.
In this file you can configure the names of the following items:
- Folder for GeneXus objects
- Generated attributes
- Generated transactions
By default this pattern generates the following transactions:
- CategoryItem - Defines Hierarchy of Categories. Each Category with CategoryFatherId null is the root.
- CategoryItemRelation - Defines the relation between Items and Category. You can apply for user friendly Category / Item relationship assignment.
Copy the files in Category.zip under C:\Program Files\ARTech\Patterns11\Patterns directory.
Next time you execute the Pattern, this pattern will be available in the list of patterns.