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:
The JSP page code calls the
InvokeAssembler
servlet bean and passes it either theincludePage
parameter, for a page request, or thecontentCollection
parameter, for a content collection request.The
InvokeAssembler
servlet bean parses theincludePath
orcontentCollection
parameter into an Assembler content request, in the form of aContentItem
.InvokeAssembler
then calls theAssemblerTools.invokeAssembler()
method, passing in theContentItem
.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 theContentItem
.The
NucleusAssembler
instance assembles the correct content for the request. Content, in Endeca terms, corresponds to a set of cartridges and their associated data. TheNucleusAssembler
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 responseContentItem
that consists of a rootContentItem
which may have sub-ContentItem
objects as attributes. ThisContentItem
hierarchy corresponds to the root cartridge and any sub-cartridges that were used to create the returned content.The
NucleusAssembler
instance recursively calls theNucleusAssembler.getCartridgehandler()
method, passing in theContentItem
type, to retrieve the correct cartridge handlers for the rootContentItem
and any of its sub-items.The cartridge handlers get resolved and executed for the root
ContentItem
and its sub-items. The resulting rootContentItem
is passed back to theNucleusAssembler
instance.Note: If a cartridge handler doesn’t 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
to theInvokeAssembler
servlet bean.When the
ContentItem
is not empty, theInvokeAssembler
servlet bean’soutput
oparam is rendered. In this example, we assume that theoutput
oparam uses adsp:renderContentItem
tag to call the/atg/endeca/assembler/cartridge/renderer/ContentItemToRendererPath
component to get the path to the JSP renderer for the rootContentItem
. However, choosing when and how many times to invokedsp:renderContentItem
depends on what the application needs to do. It may make sense to invokedsp:renderContentItem
for the rootContentItem
, and then recursively invokedsp:renderContentItem
for all the sub-ContentItems
via additionaldsp:renderContentItem
tags. Alternatively, you could take a more targeted approach where you invokedsp:renderContentItem
for individual sub-ContentItems
as needed.Note that the
dsp:renderContentItem
tag also sets thecontentItem
attribute on theHttpServletRequest
, thereby making theContentItem
available to the renderers. This value lasts for the duration of theinclude
only.The
ContentItemToRendererPath
component returns the correct renderer for theContentItem
.The JSP returned by
ContentItemToRendererPath
is included in the response.The response is returned to the browser.