Oracle Commerce Guided Search - The Assembler processing model

The Assembler processing model

The core of the Assembler is the assemble() method, which takes a content item representing a cartridge instance configuration and invokes cartridge handlers to process it into a response content item.

The Assembler uses the visitor pattern to traverse the input content item and any child content items, and invokes the appropriate cartridge handler (if any) for each of them.

The Assembler makes two passes over the input content item:

In the first pass, the Assembler calls CartridgeHandler.initialize() followed by CartridgeHandler.preprocess() on each content item in the tree. This is a pre-order traversal of the tree (working from the top of the tree down through its children), so cartridge handlers may add or modify child content items at this stage.
In the second pass, the Assembler calls CartridgeHandler.process() on each content item, which returns the response content item for that cartridge. This is a post-order traversal of the tree (working from the bottom up), so child content items are processed before the parent. The response object for the root content item of the tree (the content item originally passed in as input to the first assemble() call) contains the response objects for all its child cartridges.

The default implementation of the Assembler uses Spring to map each cartridge to the appropriate handler based on its content type. This content type corresponds to the template identifier that was used to create the content item object. If no cartridge handler is defined for a particular content type, the instance configuration is passed through as the response model.

Example

For example, consider the following content item:

NestingDollContentItemSubclass nestingDoll

This content item represents a Russian Nesting Doll. It includes properties for its name, color, and its child content item:

nestingDoll.name = "Nesting Doll"
nestingDoll.color = red
nestingDoll.child = secondNestingDoll

The secondNestingDoll contained within is green. It contains a thirdNestingDoll, which is blue. Assuming there is no cartridge handler for NestingDollContentItemSubclass, an assemble(nestingDoll) call executes the following:

The pre-order traversal starts. There is no cartridge handler for NestingDollContentItemSubclass, so no initialize() or preprocess() calls are made for nestingDoll.
Similarly, no calls are made for secondNestingDoll or thirdNestingDoll. At this point, the pre-order traversal is complete.
The post-order traversal starts. The thirdNestingDoll object is returned as-is, since there is no handler to invoke a process() method.

@type": "NestingDollTemplateType",
"name": "Nesting Doll",
"color": "red",
"child": [
    {
      @type": "NestingDollTemplateType",
      "name": "Second Nesting Doll",
      "color": "green"
      "child": [
        {
          @type": "NestingDollTemplateType",
          "name": "Third Nesting Doll",
          "color": "blue"
          "child": [] 
        }
      ],
   },
]

What if you create a cartridge handler for NestingDollContentItemSubclass that doesn't override the initialize() or preprocess() methods, but implements logic to add a property colorType of value warm or cool, based on the color property? Steps 1-2 above don't change, but Step 3 invokes the new logic, and the property shows up in the response:

@type": "NestingDollTemplateType",
"name": "Nesting Doll",
"color": "red",
"colorType": "warm",
"child": [
    {
      @type": "NestingDollTemplateType",
      "name": "Second Nesting Doll",
      "color": "green",
      "colorType": "cool",
      "child": [
        {
          @type": "NestingDollTemplateType",
          "name": "Third Nesting Doll",
          "color": "blue",
          "colorType": "cool",
        }
      ],
   },
]

Assembler Application Developer's Guide