Adobe Search And Promote and performance

Let us see the major things to be taken care to avoid performance issues while implementing Adobe S and P.
As we know search and promote has got many advantages and abundant modes of customization while

implementing for a websearch.

Usually a web can have content search and if it is a website which sells products, there are product searches available to implement. Same time we need to ensure some of the things while we implement it, which can affect the performance of search.

1) Rules implementation.

There are pre and post searches in any search process. So in Search and Promote we should ensure the post search should be minimal and it should not execute many times (need another new search = 0).

2) Templates should be light: There should not be unnecessary loops and keep temlates always light. it helps to improve the performance.

3) Filed table/attribute table implementation: Ensure the field table to be not executed during first page load. ie, always create field table when *only* required.

How to use a different Synonym Provider other than Wordnet in CQ?

When we enable spell checker in CQ5, the default synonym provider class is com.day.crx.core.query.wordnet.WordNetSynonyms which is used to perform the spell check.


WordNet uses semantic algorithms to match synonyms. The service that CQ5 is using (WordNet Search - 3.1) works with the Perl implementation of it.


Another way could be,
the spell checker can be configured by using our own properties file as mentioned below

<param name="synonymProviderClass" value="org.apache.jackrabbit.core.query.lucene.PropertiesSynonymProvider"/>

<param name="synonymProviderConfigPath" value="synonyms.properties"/>


Some cases enabling the WordNet synonym providerdo not always meet the spell check need.

Doing semantic analysis programmatically will always create some false positives. If we can live with them we could use WordNet. Otherwise we could look for a different approach based on babelnet.org or just static files.


If we want to implement an additional provider besides the existing one we would need to use a wrapper class for this.

How to do automatic versioning of asset in DAY CQ?

Through CQ it can be done as follows : http://dev.day.com/docs/en/cq/current/dam/cq5_dam_version_management.html

Let us see, is there a way where we can configure the versions to be created automatically when an asset is modified externally and uploaded back with same name?


You could do the same using VersionManager API and eventlistner. Please look at http://www.day.com/specs/jcr/2.0/15_Versioning.html. A sample example is provided @ http://wiki.apache.org/jackrabbit/ExamplesPage#Versioning_Basics.

Creating versions of a content element (including assets) is a powerful feature within the content repository API. CQ takes advantage of this feature, e.g. when you activate a page a version is created automatically.

You have to though be aware that creating versions takes a toll on your disk space. Every version created is a snapshot of the last content-element (usually the Web page). And the version folder grows fast and huge.

When you activate a 'page', a version is created automatically. However, you can always have CQ create versions automatically, although we recommend to be cautious with creating versions for assets (due to the asset size and the disk space consumption). If  want to create asset versions automatically, you want to first think when is the best time to do so. This could be e.g. when you update an asset or when you activate an asset. In both cases you can update workflows (DAM Update and/or Activate workflows).

Another way : You can also try to make changes on a page and then check "Sidekick" to see if a version has been created. Then you can do the same thing with an asset, e.g. change some meta data.

jcr:content versus _jcr_content in URL paths of AEM?

AEM seems to use "_jcr_content" when accessing any resource that is part of a page.
This also means the dispatcher seems to expect that in the URLs, since it will create the following file structure:
/page.html
/page/_jcr_content/par/other stuff and images etc.

When a page is activated/flushed/deleted, the dispatcher deletes the HTML file and the complete "_jcr_content" folder that goes with it - and all is fine.
Now when "jcr:content" is used instead, e.g. in a Javascript that loads a json, like:
/page/jcr:content/test.json
this will also work fine, because CQ/Apache Sling is able to figure out the right resource.
But the dispatcher will cache it in a subfolder like
/page/jcr:content/test.json

 The main issue here is with Windows OS that could not create folders with “:” in their name. As a result of this dispatcher cache could not be created.
On publish side CQ converts “Jcr:content” to “_jcr_content”. So always make sure that JS calls to resources in CQ publish instance had “jcr:content” converted to “_jcr_content”.

How to exclude pages / pages with specific components from the CQ dispatcher cache?

If you ever need to explicitly exclude a page or a page containing a specific component from the dispatcher cache, you can do so by setting the following response header, for example in a component's JSP, like this:

    <% 
      response.setHeader("Dispatcher", "no-cache"); 
    %> 

For more information see: http://helpx.adobe.com/dispatcher/kb/DispatcherNoCache.html.

Additional Notes:

   > you do not need to "hardcode" any content paths in your dispatcher config, but can control this dynamically from CQ. This means if you have certain page types or templates that should not be cached, you can use them dynamically anywhere in your content tree without having to modify the dispatcher cache config
   > since it is a http request header, it does not need to be added in a specific position on the HTML page. This means any component can "set" it and make the page a no-cache page.
   > you can even "switch" a previously cached page that's in the dispatcher cache directory to a dynamic no-cache version on the fly: all you need to do is activate that page OR auto-invalidate it by activating another page in the same statfileslevel subtree. The dispatcher will permanently remove the page from it's directory in that case. This allows for scenarios like: a component that requires a page not to be cached is added on to a previously cached page, the page is activated and henceforth no longer cached (the header is added to CQs response by the component).
  
   Scenarios where we can use this:
  
    #Cache (or un-cache) pages based on a component driven design - just like the example above;
    #Get away from content hierarchy or page-specific based caching designs. Earlier we had to have /ajax/dynamic/* as non-cached and any page that was not to be cached had to be put in this location (what we did for NASCAR). With this approach i can have a page anywhere and use the template to instruct dispatcher to ignore it. This would mean any new pages using same template would also follow same caching strategy;
    #Dispatcher can be configured to say "cache everything" and then i can control caching from CQ page design hence decoupling the two