Invoking the Assembler using the InvokeAssembler Servlet Bean

Invoking the Assembler from within a page, using a servlet bean, allows the call to the Assembler to occur on a just-in-time basis for the portion of the page that requires Assembler-served content. This approach is desirable when only a small portion of the page requires Assembler content. This guide refers to these pages as “Nucleus-driven pages.”

The request-handling architecture for an Nucleus-driven JSP page looks like this:

This illustration is described in the surrounding text.

In this diagram, the following happens:

  1. The JSP page code calls the InvokeAssembler servlet bean and passes it either the includePath parameter, for a page request, or the contentCollection parameter, for a content folder request.

  2. The InvokeAssembler servlet bean parses the includePath or contentCollection parameter into a request object, in the form of a RedirectAwareContentInclude object (for a page) or a ContentSlotConfig object (for a content folder). Then, the InvokeAssembler servlet bean calls the invokeAssembler() method on the /atg/endeca/assembler/AssemblerTools component and passes it the request object it created.

  3. The AssemblerTools component invokes the createAssembler() method on the /atg/endeca/assembler/NucleusAssemblerFactory component.

  4. The NucleusAssemblerFactory component returns an atg.endeca.assembler.NucleusAssembler instance.

  5. The AssemblerTools component invokes the assemble() method on the NucleusAssembler instance and passes it the request object. The handler for the request object (which may be the RedirectAwareContentIncludeHandler or ContentSlotConfigHandler, depending on the type of request object passed in) resolves a connection to the Workbench and/or the MDEX. For page requests, the handler also invokes a series of other components that transform the request URL into a URI that contains the path to the page in Experience Manager.

  6. The NucleusAssembler instance assembles the correct content for the request URI. Content, in this case, corresponds to a hierarchical set of cartridges and their associated data. For each cartridge, the content starts with any default data that was specified in the Experience Manager cartridge configuration files when the cartridge was added to the page. That data is further modified and augmented with any data stored in the Oracle Commerce Configuration Repository (that is, changes made and saved via the Experience Manager UI).

  7. Next, the NucleusAssembler instance calls the NucleusAssembler.getCartridgehandler() method, passing in the cartridge’s ContentItem type, to retrieve the correct handler for the cartridge. The handler gets resolved and executed and the results are stored in the cartridge’s associated ContentItem. This process happens recursively so that the assembled content takes the form of a response ContentItem that consists of a root ContentItem which may have sub-ContentItem objects as attributes.

    Note: If a cartridge handler does not exist for a ContentItem, the initial version of the item, created in step 6, is returned.

  8. The NucleusAssembler instance returns the root ContentItem to the AssemblerTools component.

  9. The AssemblerTools component returns the root ContentItem to the InvokeAssembler servlet bean.

  10. When the ContentItem is not empty, the InvokeAssembler servlet bean’s output oparam is rendered. In this example, we assume that the output oparam uses a dsp:renderContentItem tag to call the /atg/endeca/assembler/cartridge/renderer/ContentItemToRendererPath component to get the path to the JSP renderer for the root ContentItem. However, choosing when and how many times to invoke dsp:renderContentItem depends on what the application needs to do. It may make sense to invoke dsp:renderContentItem for the root ContentItem, and then recursively invoke dsp:renderContentItem for all the sub-ContentItems via additional dsp:renderContentItem tags. Alternatively, you could take a more targeted approach where you invoke dsp:renderContentItem for individual sub-ContentItems as needed.

    Note that the dsp:renderContentItem tag also sets the contentItem attribute on the HttpServletRequest, thereby making the ContentItem available to the renderers. This value lasts for the duration of the include only.

  11. The ContentItemToRendererPath component returns the correct renderer for the ContentItem.

  12. The JSP returned by ContentItemToRendererPath is included in the response.

  13. The response is returned to the browser.

Copyright © 1997, 2016 Oracle and/or its affiliates. All rights reserved. Legal Notices