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 “ATG-driven pages.”

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

In this diagram, the following happens:

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

  2. The InvokeAssembler servlet bean parses the includePath or contentCollection parameter into an Assembler content request, in the form of a ContentItem. InvokeAssembler then calls the AssemblerTools.invokeAssembler() method, passing in the ContentItem.

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

  6. The NucleusAssembler instance assembles the correct content for the request. Content, in Endeca terms, corresponds to a set of cartridges and their associated data. The NucleusAssembler instance starts with the data in the Endeca Experience Manager cartridge configuration files and then modifies that data with information stored in the Endeca Content Repository (that is, changes made and saved via the Experience Manager UI). The assembled content takes the form of a response ContentItem that consists of a root ContentItem which may have sub-ContentItem objects as attributes. This ContentItem hierarchy corresponds to the root cartridge and any sub-cartridges that were used to create the returned content.

  7. The NucleusAssembler instance recursively calls the NucleusAssembler.getCartridgehandler() method, passing in the ContentItem type, to retrieve the correct cartridge handlers for the root ContentItem and any of its sub-items.

  8. The cartridge handlers get resolved and executed for the root ContentItem and its sub-items. The resulting root ContentItem is passed back to the NucleusAssembler instance.

    Note: If a cartridge handler doesn’t exist for a ContentItem, the initial version of the item, created in step 8, is returned.

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

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

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

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

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

  14. The response is returned to the browser.

Copyright © 1997, 2012 Oracle and/or its affiliates. All rights reserved.

Legal Notices