Unofficial Content
  • This documentation is valid for:

Name

The name is self descriptive in that this pattern is used to categorize items.

See Difference between Type and Category.

Intention
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

Category Pattern Instance File

The Instance File has the following nodes:

 CategoryInstance

ItemTransaction - In this case Item Transaction.
AttributesName - Name of the attributes for CategoryItemRelation Transaction.

Category.Config

In this file you can configure the names of the following items:

  • Folder for GeneXus objects
  • Generated attributes
  • Generated transactions
Generated GeneXus Objects

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.
Sample

CategorySample

Installation

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.

Last update: April 2024 | © GeneXus. All rights reserved. GeneXus Powered by Globant