Wednesday, 27 March 2013

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.

Tuesday, 26 March 2013

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.

Thursday, 14 March 2013

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