The request-handling architecture for an Assembler-driven JSP page looks like this:
In this diagram, the following happens:
The application server receives a request.
The application server passes the request to the Oracle Commerce Core Platform request handling pipeline.
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
.The
AssemblerPipelineServlet
determines if the request is for a page or a content folder in Experience Manager and creates either aRedirectAwareContentInclude
object (for a page) or aContentSlotConfig
object (for a content folder). Then,AssemblerPipelineServlet
calls theinvokeAssembler()
method on the/atg/endeca/assembler
/AssemblerTools
component and passes it the request object it created.The
AssemblerTools
component invokes thecreateAssembler()
method on the/atg/endeca/assembler
/NucleusAssemblerFactory
component.The
NucleusAssemblerFactory
component returns anatg.endeca.assembler.NucleusAssembler
instance.The
AssemblerTools
component invokes theassemble()
method on theNucleusAssembler
instance and passes it the request object. The handler for the request object (which may be theRedirectAwareContentIncludeHandler
orContentSlotConfigHandler
, 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.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).Next, the
NucleusAssembler
instance calls theNucleusAssembler.getCartridgehandler()
method, passing in the cartridge’sContentItem
type, to retrieve the correct handler for the cartridge. The handler gets resolved and executed and the results are stored in the cartridge’s associatedContentItem
. This process happens recursively so that the assembled content takes the form of a responseContentItem
that consists of a rootContentItem
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.The
NucleusAssembler
instance returns the rootContentItem
to theAssemblerTools
component.The
AssemblerTools
component returns the rootContentItem
toAssemblerPipelineServlet
.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 rootContentItem
. TheContentItemToRendererPath
component uses pattern matching to match theContentItem
type to a JSP file; for example, in Commerce Reference Store, if theContentItem
type isBreadcrumbs
, the JSP file is/cartridges/Breadcrumbs/Breadcrumbs.jsp
.Note: See ContentItemToRendererPath for more details on how the renderer path is calculated.
The
AssemblerPipelineServlet
component sets the assembledContentItem
as acontentItem
parameter on theHttpServletRequest
, then forwards the request to the JSP determined by theContentItemToRendererPath
componentDue to the nested nature of
ContentItems
, the JSP for the rootContentItem
may have to render sub-ContentItem
s, and those sub-ContentItems
may have their own sub-ContentItems
as well. As such, each JSP renderer, from the root on down, must includedsp:renderContentItem
tags for its immediate sub-ContentItems
. This configuration creates a recursive scenario that allows all sub-ContentItems
to be rendered.The
dsp:renderContentItem
tag invokes theContentItemToRendererPath
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 thecontentItem
attribute on theHttpServletRequest
, thereby making each sub-ContentItem
available to its renderer; however, this value lasts only for the duration of theinclude
so that after theinclude
is done, thecontentItem
attribute’s value returns to the rootContentItem
.The JSPs returned by the
ContentItemToRendererPath
component are included in the response.The response is returned to the browser.