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

This illustration is described in the following text.

In this diagram, the following happens:

  1. The application server receives a request.

  2. The application server passes the request to the Oracle Commerce Core Platform request handling pipeline.

  3. The request handling pipeline does some preliminary work, such as setting up the profile and determining which Oracle Commerce Platform site the request is for. At the appropriate point, the pipeline invokes the /atg/endeca/assembler/AssemblerPipelineServlet.

  4. The AssemblerPipelineServlet determines if the request is for a page or a content folder in Experience Manager and creates either a RedirectAwareContentInclude object (for a page) or a ContentSlotConfig object (for a content folder). Then, AssemblerPipelineServlet calls the invokeAssembler() method on the /atg/endeca/assembler/AssemblerTools component and passes it the request object it created.

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

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

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

  8. The NucleusAssembler instance assembles the 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).

  9. 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 8, is returned.

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

  11. The AssemblerTools component returns the root ContentItem to AssemblerPipelineServlet.

  12. The AssemblerPipelineServlet component calls the /atg/endeca/assembler/cartridge/renderer/ContentItemToRendererPath component to get the path to the renderer (in this case, a JSP file) for the root ContentItem. The ContentItemToRendererPath component uses pattern matching to match the ContentItem type to a JSP file; for example, in Commerce Reference Store, if the ContentItem type is Breadcrumbs, the JSP file is /cartridges/Breadcrumbs/Breadcrumbs.jsp.

    Note: See ContentItemToRendererPath for more details on how the renderer path is calculated.

  13. The AssemblerPipelineServlet component sets the assembled ContentItem as a contentItem parameter on the HttpServletRequest, then forwards the request to the JSP determined by the ContentItemToRendererPath component

  14. Due to the nested nature of ContentItems, the JSP for the root ContentItem may have to render sub-ContentItems, and those sub-ContentItems may have their own sub-ContentItems as well. As such, each JSP renderer, from the root on down, must include dsp:renderContentItem tags for its immediate sub-ContentItems. This configuration creates a recursive scenario that allows all sub-ContentItems to be rendered.

  15. The dsp:renderContentItem tag invokes the ContentItemToRendererPath component to retrieve the JSP renderer for the current sub-ContentItem. The retrieved JSP is then included in the rendered page.

    The dsp:renderContentItem tag also sets the contentItem attribute on the HttpServletRequest, thereby making each sub-ContentItem available to its renderer; however, this value lasts only for the duration of the include so that after the include is done, the contentItem attribute’s value returns to the root ContentItem.

  16. The JSPs returned by the ContentItemToRendererPath component are included in the response.

  17. The response is returned to the browser.


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