Archive for the ‘Adobe Day’ Category

Best Practices for developing CQ components/ tips and tricks

Monday, August 13th, 2012

CQ community is growing many folds in recent times and so is the demand to reach to the right content. As an initiative, Adobe is trying to collaborate information from various resources to a common platform. Here are some useful urls where I have contributed:

Tips and tricks from the CQ community

Developing CQ components | Best practices

Enjoy reading !

CQ – Tips and Tricks

Friday, January 6th, 2012

I have recently started a sub-domain to cover Adobe Day CQ specific information, pertaining from design options, to components to various tips and tricks I came across during my CQ experience.

CQ Tips and Tricks

I hope it will be useful for Adobe CQ world !

Choosing a CMS: Have you considered upgrade process?

Tuesday, September 27th, 2011

There are lots of sites/advisory papers which talk about how to choose a right WCM for your needs. And I am not going to re-invent the wheel here. But there is one aspect which is always given less importance and usually neglected during CMS selection and that is the upgrade process.

Usually upgrades shouldn’t be too tricky as most of the upgrade does is change some schema definition and update existing product code base. So why it needs to be considered at CMS selection process? Read on !

Most of the big WCM Implementations need customisation of some sort and so upgrade projects become more tricky when product overwrite these customisations. A lot of it depends on the under lying architecture of the product. Lets consider two well known products: Oracle WebCentre (previously Fatwire) and Adobe Day CQ. Adobe Day CQ provides facility to overwrite the default components and configurations by simply extending them within your own project. Customisations are achieved without modifying any of the system files, provided its implemented based on CQ recommendations. So, upgrade path for CQ is pretty straight forward and shouldn’t cause sleepless nights.

On the other hand, consider Oracle webcentre where customisation could be achieved only by modifying the underlying system elements. Even your implementation follows the Fatwire recommended approach for customisations, it will lead to changes to system elements. What that means is that upgrade is not straight forward and upgrade itself becomes a project in its own where time lines vary with the number of such customisations.

In a short period product A might satisfy your requirements more than product B, but its important to look at the longer picture because something which looks cool and easy to implement and run might not get you the expected returns in future. And considering the way technology is changing, no one can move away from not upgrading their products for long.

WCM & Configuration Management

Friday, June 10th, 2011

As highlighted recently by @irina_guseva from Real Story Group, C stands for complexity in WCM, one other reason to add for this complexity is around availability of development tools and the whole process of configuration management and continuous integration. Lots of CM systems are repository based and they love to manage content, content types and presentation templates within the repository than on file system. As most of the CM system provides versioning, all the configuration managment, whether to do with content, content types or presentation are all buried within them.

Over the period of time, the above approach has lead to many CMS implementation failures or the thought of using CMS at the first place. Configuration and deployment process is the least which is talked about during product demo’s and presentation but always is an area of concern. One, there is no way to manage your configurable items in a Concurrent Version System. Two, deployments are hand-crafted than any automated tools. Three, there are lot of manual processes required to be in place to manage change control and many such reasons. And if you have a big team, anything more than five, it is really a nightmare. Resolving conflicts, managing communication around changes, keeping track of the changes etc. adds just new dimension to complexity.

Many CMS vendors have realized the problem area and the result is inclusion of development tools/ IDE’s with the product. Adobe’s Day CQ comes with CRXDE which is custom-built,pre-packaged, stand-alone Eclipse application specifically for CQ and CRX and thus enables to efficiently develop project. Fatwire’s 7.6 version now comes with CSDT (Content Server Developer Developer Tools) which enable developers to work in a distributed environment using tools such as the Eclipse Integrated Development Environment (IDE) and version control system (VCS) integration. Both of these developer tools expose the repository structure in file system which enables all the doors for configuration management.

Once the files are available on a file system, it is pretty straight forward to integrate with a CVS system for config management and providing a much cleaner development environment for big teams. It also enables for continuous integration plus automated delpoyments. Config management becomes managable and the complexity suddenly dis-appears.

I think going forward, we will see more development tools evolving for products, enabling customers to focus of real CMS issues than management and release processes with these tools.

Adobe’s Day CQ 5.3 – My view of the product

Thursday, May 26th, 2011

Day CQ has been in news ever since Adobe decided to acquire the company. Firstly, it was around providing a WEM platform along with Adobe’s online marketing suite and than as highlighted by @irina_guseva from RSG, CQ5 WCM development skills are hot — and scarce. I recently had some hands-on experience in exploring the porduct and we launched three websites in the space of five months, which clearly highlights one of the main strengths of the product i.e. quick time to market. There are lots of positives about the product. To list a few are:



  • Easy to setup and get started
  • Architecture (Open source + standards)
  • Sling framework is pretty cool ! .html to .xml to .json etc
  • Jackrabbit, Felix OSGi bundles JCR 283 Standards compliant
  • Default cluster of one, so easy to add remove new instances
  • Syndication/ content sync is pretty fast
  • Packaging architecture is neat
  • System backups
  • Blogs (reverse publishing)
  • etc

And there are lot of sites which talk about its positivity. There are always two sides of the coin, and product does have some not soo good aspects as well. Find below the list which might be useful for users who are trying to evaluate CQ. The below list is based on my experience and I am happy if any of the CQ guru’s want to correct me:



  • Separation of component and content: The component model doesn’t really highlight the real value of a CMS product. Most of the components which comes out of the box doesn’t really separate content from presentation and I fould it hard until we adoped the approach of data components and presentation components. For more details, please refer to my old post: Adobe’s Day CQ : Separation of content from components
  • Multi Vendor and issue with CSS /Divs: CQ requires HTML, CSS to be defined in specific formats, as it adds a number of divs on its own to establish its paragraph system. If you are working in multi-vendor environment, where a creative agency is developing designs and mock-ups without any clue of CQ, it may sometimes be really hard to adopt it in CQ. It is better to look for some guidelines from CQ around the structure of HTML, CSS to be defined.
  • Thin Documentation: Even though has basic set of documentation available, it is really hard if you want to customize even a small bit of it. The architecture is pretty open but unless there are pointers to explore its really a big hinderance. The google groups CQ forum has more of queries than solutions, but recently it has been pretty busy.
  • Authoring WCM User Interface: UI for authors is Ajax based, and so it is an issue in organisations where JS is disabled. With JS disabled, the interface comes back as blank page.
  • CRXDE: Popular tool for development is CRXDE but we had troubles in its integration with SVN. The updates didn’t work as expected and you can’t check-out a single file. There is no proper guidelines to merge and resolve conflicts apart from doing it outside CRXDE
  • Reporting: Out of the box reporting available within CQ 5.3 is pretty thin and you need to write custom code to extract most of the required information. This has changed significantly with V 5.4.
  • Package Manager: New package manager with CQ 5.3 has number of issues and in my experience it is better to use the old package manager which is more reliable. Also, the UI for pacakge manager doesn’t refesh and hangs for ages.
  • Multiple interfaces: CQ comes with number of interfaces including WCM, CRX, Apache Felix, servlet engine administration. Some of the functionalities re overlapping across interfaces. It will be better to consolidate into one.
  • CQ Corruption: We have seen a situation where CQ stopped working just because someone switched off the machine while CQ was running. It happened to be that CRX repository was out of sync on local and shared directories which didn’t allow CQ to start again.
  • Sidekick is sleak but annoying and does page refresh for each action

If anyone wants to share their not so good experience with CQ please drop a comment or mail me and I will consolidate as part of the above post.

Discussion:Adobe’s Day CQ : Separation of content from components

Sunday, March 20th, 2011

Few days back I posted some information around Day’s CQ Separation of Content from Components. There was some good discussion around the topic in one of the CQ group. Here is information from group discussion:

From Paul McMahon, Acquity Group

I think this is a common mis-perception – that because a component defines both content and presentation that the content and presentation are somehow linked.

Yes the component does have presentation logic associated to it, but the content is stored without the presentation, as raw content. This means that that content can be reused in many places without calling on the presentation of the component that was used to create the content.

So let’s take you restaurant example. You might define a restaurant component, which would include all the attributes of a restaurant in it’s dialog, and provide the presentation for a restaurant detail page.

Now lets say you want to have a restaurant listing component. This components content would be limited to say title and column headings for example. In the code of you component you execute a search on the repository looking for all nodes where sling:resourceType = yourrestuarantComponent. This search returns all the nodes where restaurant details were entered. You iterate over this nodes, grab the content you want to display and you display it in the presentation layer you need for the listing page. No duplication of content and you retain the ability to edit the content in it’s natural home within the site.

Now that said I often create the sort of plain jane content entry components and templates you are describing when dealing with content that has no natural home, but that is more about content organization and business process than it is about separation of content and presentation layer.

You can also use the scaffolding mechanism to achieve similar results, but in a different manner.


Adobe’s Day CQ : Separation of content from components

Tuesday, March 15th, 2011

I am almost two impelementation’s old with Day’s CQ WEM. When I started with CQ product, one thing which kept me guessing within CQ was the separation of content from presentation.

As per my understanding of CQ, a component is the one which holds data, dialogs to capture information and presenting the information. One of the ground rule for a CMS system is separation of content from presentation but its initial usage looks to voilate this rule. If the same content is presented in three different formats, it is pretty common in CQ to end up adding the same content three times through different components usage. And if the site is pretty huge, I can easily image the content getting out of sync soon within the same site, not even accounting for any external interfaces.

No doubt, CQ is pretty powerful and its underlying architecture can allow you to do almost everything, along with its paragraph system. For our implementations, we followed an approach as described below. I am sure this is nothing new but I never saw such information on sites, so I thought of putting togather this post. In order to achieve separation of content from presentation, we defined three different categories of components:

Data Components: These are data buckets which holds data without any presentation logic built into them. It presents user with a dialog box along with various tabs to capture information.

Presentation Components: These are components which extract information from data components and display the content in the desired format.

Common components: There are common set of properties defined to capture common assets information either as part of data component or presentation component.

Let me try to explain with an example:

Suppose there is a need to build a website for hospitality group which has number of restaurants scattered across the globe. These restaurants are logically grouped into regions, for example, Asian, European, American etc. As part of restaurant, there is a need to capture information including: Name of the restaurant, Location, Region, image of the restaurant, Description of the place, Opening hours, facilities etc. The information for restaurants are displayed on various pages, on the restaurants home page, maps pages, regional pages etc.


Adobe WEM = CQ 5.4 + Adobe’s Online Marketing Suite => Mobile Web

Tuesday, February 22nd, 2011

Adobe’s announcement around their WEM (Web Experience Management) Suite comprises of :

Adobe's WEM

Adobe's WEM. Source:

Looking at the above list, it could be one of the leaders in the area of WEM providing all the capabilities. I will cover details about each of the modules in my next post. But one important module which I wanted to highlight is CQ5 Mobile. Here is some description about CQ5 Mobile from Adobe’s site:

It is increasingly important that websites offer specific “views” for mobile devices, where these “views” typically are separate sites that share some content with the “normal” website. CQ assists you in creating mobile websites: when authoring a mobile page, the page is displayed in a way that emulates the mobile device, called an emulator. When authoring the page, you can switch between several emulators to get a real view of what the end-user will see when accessing the page.

In the out-of-the-box version, devices have been grouped into three categories – feature, smart and touch – according to the capabilities of the devices to render a page . CQ allows to create new device groups. When the end-user accesses a mobile page, CQ detects the device and sends the representation that corresponds to its device group.

CQ enables you to create a mobile site based on an existing standard site. It can be simply achieved by creating a livecopy of the standard site.

This defintely links back to my previous post :Content Delivery over Mobile: Mobile Apps Vs Mobile Web? this definitely a step towards mobile web over mobile applications for future trends.