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

How to set permission on a Dam-asset for a component?

Let us see how do we set permissions

How to set permissions for thumbnail-image renditions for a dam asset. for example: even if a user does not logged in(where an anonymous user does not have permission to that asset), he can see thumbnail image of that asset, but can not access it.


This can be achieved by setting up following allow node using glob permission policies which allow to set up permission on basis of patterns. This configuration will be required at the node/path where the permission is denied for anonymous user-


    <allow
        jcr:primaryType="rep:GrantACE"
        rep:glob="*cq5dam.thumbnail.*"
        rep:principalName="<anonymous user/ group>"
        rep:privileges="{Name}[jcr:read]"/>


As the thumbnail files in cq5 starts with name - cq5dam.thumbnail, above pattern for glob permissions policy sets up read permission for required user/group for all the files starting with above name under the given path.

Where the data in CRX Repository saved when we enter in Dialog and Design Dialog box respectively?

CQ has two types of dialogs:

    "dialog": The content entered with this dialog is stored directly to the paragraph on the current page.
    "design_dialog": The content entered is stored to a "design page" created in /etc/designs.



In previous versions of CQ, back to CQ 4, the idea of the design dialog was to store content in a place other than the paragraph of the current page. Since in the early days this type of content was related mostly to design content (e.g. font size of a navigation, etc.) this page was called a "design page".

The design page is assigned to a content page via "page properties". In the page properties you can select a design page and every new child page you create will "inherit" that design page. If there is no custom design page, then the "default" design page will be used (/etc/designs/default). Note that you cannot do anything with the design page, it's simply a node to collect content provided via "design_dialog". So if you have content you want to share among the child pages, you can use a design dialog so store it to a design page.

Hope this helps.