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
InvokeAssemblerservlet bean and passes it either theincludePageparameter, for a page request, or thecontentCollectionparameter, for a content collection request.The
InvokeAssemblerservlet bean parses theincludePathorcontentCollectionparameter into an Assembler content request, in the form of aContentItem.InvokeAssemblerthen calls theAssemblerTools.invokeAssembler()method, passing in theContentItem.The
AssemblerToolscomponent invokes thecreateAssembler()method on the/atg/endeca/assembler/NucleusAssemblerFactorycomponent.The
NucleusAssemblerFactorycomponent returns anatg.endeca.assembler.NucleusAssemblerinstance.The
AssemblerToolscomponent invokes theassemble()method on theNucleusAssemblerinstance and passes it theContentItem.The
NucleusAssemblerinstance assembles the correct content for the request. Content, in Endeca terms, corresponds to a set of cartridges and their associated data. TheNucleusAssemblerinstance 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 responseContentItemthat consists of a rootContentItemwhich may have sub-ContentItemobjects as attributes. ThisContentItemhierarchy corresponds to the root cartridge and any sub-cartridges that were used to create the returned content.The
NucleusAssemblerinstance recursively calls theNucleusAssembler.getCartridgehandler()method, passing in theContentItemtype, to retrieve the correct cartridge handlers for the rootContentItemand any of its sub-items.The cartridge handlers get resolved and executed for the root
ContentItemand its sub-items. The resulting rootContentItemis passed back to theNucleusAssemblerinstance.Note: If a cartridge handler doesn’t exist for a
ContentItem, the initial version of the item, created in step 8, is returned.The
NucleusAssemblerinstance returns the rootContentItemto theAssemblerToolscomponent.The
AssemblerToolscomponent returns the rootContentItemto theInvokeAssemblerservlet bean.When the
ContentItemis not empty, theInvokeAssemblerservlet bean’soutputoparam is rendered. In this example, we assume that theoutputoparam uses adsp:renderContentItemtag to call the/atg/endeca/assembler/cartridge/renderer/ContentItemToRendererPathcomponent to get the path to the JSP renderer for the rootContentItem. However, choosing when and how many times to invokedsp:renderContentItemdepends on what the application needs to do. It may make sense to invokedsp:renderContentItemfor the rootContentItem, and then recursively invokedsp:renderContentItemfor all the sub-ContentItemsvia additionaldsp:renderContentItemtags. Alternatively, you could take a more targeted approach where you invokedsp:renderContentItemfor individual sub-ContentItemsas needed.Note that the
dsp:renderContentItemtag also sets thecontentItemattribute on theHttpServletRequest, thereby making theContentItemavailable to the renderers. This value lasts for the duration of theincludeonly.The
ContentItemToRendererPathcomponent returns the correct renderer for theContentItem.The JSP returned by
ContentItemToRendererPathis included in the response.The response is returned to the browser.

