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)
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 dev.day.com 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.