Friday 17 July 2015

Connecting AEM 6 with Microsoft SQL Server

Some old applications that you might want to migrate to AEM might still use SQL Server databases. Here are the steps to access an external SQL server from AEM 6:

Building the OSGI bundle for the JDBC driver:

1. Download the appropriate driver from here 
2. Unzip the downloaded driver.
3. Open eclipse indigo.
4. Click on File-> New -> Other -> Plugin from existing JAR archive 
5. Click on Add External and enter the path of the downloaded jar
6. Enter Plugin properties as shown here:
7. Observe the MANIFEST.MF, it shall look like this:
8. Save the project.
9. Right click the project --> Export --> Plug-in Development --> Deployable plug-ins and fragments
10. Choose a directory location --> Save.
11. The OSGI jar is available at the given-directory-location/plugins

Uploading the OSGI jar in felix:

1. Go to http://localhost:4502/system/console/bundles
2. Click on Install/Update
3. Upload the jar:
4. The jar should come in Active state. Look for errors in the error log if it still shows "Installed":
5. Error Log might show:
org.osgi.framework.BundleException: Unresolved constraint in bundle com.myproject.jdbc [398]: Unable to resolve 398.0: missing requirement [398.0] osgi.wiring.package; (&(osgi.wiring.package=javax.xml.transform.stream)(version>=1.3.0))
The bundle might also show unresolved dependencies:
6. Edit the MANIFEST.MF to remove the versions for resolving dependencies:
7. Re-install the bundle and it should be active now:


JDBC Connection Pool Factory config:

1. Go to http://localhost:4502/system/console/configMgr
2. click on "+" to add a configuration:
3. The configuration looks like this:





Test Connection:

1. An example code snippet for testing the connection:


Note: You might have to allow your Microsoft SQL server to accept remote connections! Please refer this

Hope this helps!!!






Monday 18 May 2015

Hide extra component divs in CQ/AEM

This can be really tedious sometimes when, while developing a component in CQ/AEM, the extra CQ generated divs surrounding your component might disturb the HTML structure intended.

A common usecase is a carousel component in which, lets suppose, for every slide we drop in the carousel wrapper, no extra component div is required just to make sure the plugin driving the carousel runs fine.

An ideal structure would be :
<ul>
<li></li>
<li></li> 
<li></li>  
<li></li>
</ul>

If each li comes from a carousel slide component, here is what it looks like in cq:

<ul>
<div class="carousel-slide"><li></li</div>
<div class="carousel-slide"><li></li</div> 
<div class="carousel-slide"><li></li</div>  
<div class="carousel-slide"><li></li</div>
</ul>

This structure sometimes prevents the carousel JS plugins to stop behaving the way they should.

Solution:
One of the alternatives is to use cq:noDecoration="true", but that makes the component un-editable. Neither the editconfig not the dialog is visible.
Thus, an ideal approach would be :

Just before cq including the component, add this code snippet:

 <%
                        IncludeOptions opts = IncludeOptions.getOptions(request, true);
                        opts.setDecorationTagName("");

 %>
This would require an import:
<%@ page import="com.day.cq.wcm.api.components.IncludeOptions" %>

Now cq inlcude your component, for eg:

<cq:include path="slide"> resourceType="/component/content/carousel-slide"/>

Hope this helps! 

Friday 27 February 2015

Hide a parsys in CQ edit mode

Often, a situation is encountered in CQ where we have a number of parsys on our page and it is required to show/hide some of them on certain events. A typical use case is that of a Tabbed Component where the parsys associated with a particular tab needs to be shown only on click of that particular tab while the parsys for all the other non active tabs should be hidden.
If my parsys is wrapped by a container div something like this.
<div class="genericTabContent"><cq:include path="par" resourceType="foundation/components/parsys" />
</div>
Then, calling the .hide() method on the div doesn't hide the parsys. Rather, the parsys is visible floating somewhere on the page making the authoring experience very tough.
parsys1
All attempts to hide the parsys through CSS seem to fail.
A possible solution is :
var parsysComp = CQ.WCM.getEditable("path to the parsys");
parsysComp.hide(); // makes the parsys visible
parsysComp.show(); // hides the parsys
To get the path to the parsys, the current node path can be fetched on our jsp page:
<div id="currentNodePath" class="${currentNode.path}"></div>
Once the current node path is known, this code snippet would work:
var parsysComp = CQ.WCM.getEditable(('#currentNodePath').attr('class')+"/par");
Hope this was helpful!