Skip to main content

ATG Search - high level overview of product-catalog-output-config.xml and XHTMLs

  • The definition file format begins with a top-level item element that specifies the repository and item descriptor to use, and then lists the properties of that item type to include.
  • The top-level item element has the is-document attribute set to true. This attribute specifies that an XHTML document should be generated for each item of that type (in this case, each user item).
  • Property values that come from standard JavaBean properties of the RepositoryItem object (rather than dynamic bean properties) are specified using a dollar-sign ($) prefix.
  • The item element has an is-multi attribute for specifying multi-value properties. If a property is an Array, Collection or Map  you should set this attribute to true.
  • Eeach ATG Search document is uniquely identified by a URL (typically the path name of the file on the file system).
  • In the XHTML documents that the ATG platform generates from repository items, meta properties are represented by meta tags in the head of the document, while text properties are represented by div tags in the body of the document.
  • ATG uses a URL of the following form to uniquely identify each document:       atgrep:/repository-name/item-descriptor-name/repository-id
  • In addition to the properties you specify in the definition file, the output document also includes certain properties that provide sufficient information to identify the repository items represented in the document. The output for each item automatically includes the properties $repositoryId, $repository.repositoryName, and $itemDescriptor.itemDescriptorName.
  • The output for the document-level item also includes a $url property and a $baseUrl property, where each contain the URL representing this repository item. (The difference between these properties is that if a VariantProducer( Eg: locale specific) is used to generate multiple documents from the same repository item, the $url property for each document will include unique query arguments to distinguish the document from the others.)
  • At a minimum, you need to set the following properties on each IndexingOutputConfig component: bulkLoader , definitionFile.
  • The IncrementalLoader component uses an implementation of the PropertiesChangedListener interface to monitor the repository for add, update, and delete events. It then analyzes these events to determine which ones necessitate updating XHTML documents and creates a queue of the affected repository items. When a new incremental update is triggered, the IncrementalLoader processes the items in the queue, generating and loading a new XHTML document for each changed repository item.
  • PropertyAccessor defines how the document loaders obtain property values
  • VariantProducer specifies logic for creating multiple XHTML documents from the same repository item.

Comments

Popular posts from this blog

ATG - more about Forms and Form Handlers

An ATG form is defined by the dsp:form tag, which typically encloses DSP tags that specify form elements, such as dsp:input that provide direct access to Nucleus component properties. Find below a sample dsp:form tag.    <dsp:form action="/testPages/showPersonProperties.jsp" method="post" target="_top">      <p>Name: <dsp:input bean="/samples/Person.name" type="text"/>      <p>Age: <dsp:input bean="/samples/Person.age" type="text" value="30"/>      <p><dsp:input type="submit" bean="/samples/Person.submit"/> value="Click to submit"/>    </dsp:form>   When the user submits the form, the /samples/Person.name property is set to the value entered in the input field.Unlike standard HTML, which requires the name attribute for most input tags; the name attribute is optional for DSP form element tags. If an input tag omits the n...

Basic design decisions for a commerce search setup ( with an ATG Search view)

In this blog I would like to explain the basic set of configuration/design decisions needed to setup an ATG search project. Most of these design decisions are common for all Enterprise search applications. 1. Decide the searchable properties :   This means the properties that the business want the user to search in the ecommerce platform. In ATG search these are configured as the text properties in the product-catalog-output-config.xml ( the definitionFile of the \atg\commerce\search\ProductCatalogOutputConfig). Usually the displayName of product/sku, displayName of department/category/sub-category, skuId, brandName are the properties configured as searchable. 2. Decide the search refinement properties or the faceted properties :   After a user search for a keyword, search refinement is the next step done to filter his results. ATG supports the search refinement using the Faceted Search concept. Read more about facted search @...

Google Chrome shortcut keys

If you are a Google Chromey guy, please find below the list of shortcut keys for some of the most used features  :-) Find more shortcut keys @  http://www.google.com/support/chrome/bin/static.py?page=guide.cs&guide=25799&topic=28650

ATG Search architectural flow : Search and Index

I would like to explain the high level ATG Search implementation architecture ( for an online store) through the above diagram. In this diagram 1.x denotes the search functionality and 2.x denotes the indexing functionality. I have given JBoss as the application server. Physical Boxes and Application Servers in the diagram ( as recommended by ATG )  : Estore ( Commerce ) Box --> The box with the estore/site ear (with the site JSPs and Java codes). Search Engine Box --> The box with the search engine application running. Indexing Engine Box --> The box with the indexing engine application running. CA (Content Administration) Box --> The box with the ATG CA ear ( where we could take CA -BCC - Search Administration and configure the search projects) . Search Indexer Box --> The box with the ATG Search Index ear ( to fetch the index data from repository). Note that the engine performing indexing will need access ...

ATG Search - how estore(commerce instance) forms the search engine SOAP URL ?

The comminucation between the Commerce box and the Search engine is through SOAP. Read  more about this architecture @  http://tips4ufromsony.blogspot.in/2011/11/atg-search-architectural-flow-search.html The commerce instance forms the SOAP url just like the below code: private URL getSearchEngineURL(SearchEngine engine) {       SearchEnvironmentHost h =  engine.getSearchEnvironmentHost();       SearchMachine hi = h.getSearchMachine() ;       return new URL( "http://" + hi.getHostname() + ":" + engine.getPort() + "/AEXmlService/" );   } So the commerce instance need the hi.getHostname()  and engine.getPort() to form the url. It is obtained as below: 1. The component / atg/commerce/search/refinement/ CommerceFacetSearchService has the siteName defined, which will be pointing to the environment name defined in the Search Project. Read  more about this search project setup @  http://...