Posts Tagged ‘CRX’
CQ5 Training: Day 3
Saturday, January 17th, 2009
This was the last day of our CQ5 training.
The new dialog editor is nice. Using the old dialog editor was about as much fun as explaining to your wife why you needed to buy that new Blu-ray player. The UI is very clean, and it has been AJAXified. Actually, the editor itself is an Ext JS widget. Pretty cool. No more trying to double click in the right area in order to get the properties of a field displayed for editing. However, the bad news is that new dialog editor suffers from the same issue that the previous one did. Not all of the widgets are available to choose from. The good news is that this appears to be configurable. After all, it is itself an Ext JS widget. I found a file where the available widgets (for the dialog editor) and their properties are defined (/libs/widgets/cq-widgets.js/files/widgets/DialogEditorConstants.js) and I’m guessing you can just modify it. It is still a good way to get started. You can always modify it by hand later.
CQ5 Training: Day 1
Wednesday, January 14th, 2009
I just finished my first day of training with CQ5. I’ve been using it for a few weeks and I already have a few throughts. However, I’m going to hold off on those and limit this post to just my thoughts on what was reviewed today.
JCR Search: SQL or XPath?
Tuesday, September 16th, 2008
So, I’ve been working on a RESTful application to expose content in CRX added by authors in CQ to other applications.
I’ve been using the SQL syntax. I suppose this is because my background includes data architecture and modeling. Yes, I have a black belt SQL Kung Fu. Now we are considering using the XPath syntax instead. I noticed that the JCR specification suggests that database backed repositories are limited in the number of efficient XPath queries they can support. The key word there for me was ‘efficient’. It also notes that, for database backed repositories, XPath queries are translated to SQL queries. So that got me thinking. Should I continue to use the SQL syntax and database backed repositories, or not? Actually, for maintenance purposes, I’ve already suggested that we move to the Tar persistence manager. I suppose I’ll switch to the XPath syntax then.
What do you think?
So until next time, good fight, good night.
Critique: CQ, CRX, & the JCR API
Wednesday, September 10th, 2008
I’ve been working with CQ for the last few years. I’ve been working directly with JCR API for the last several months. Finally, I decided to read the JCR specification. I was surprised (well maybe not too much) to see that CQ discards quite a few JCR features in favor of implementing them within the application logic. Personally, I’m not too happy about that. If a feature is supported by the repository, why reinvent the wheel in your application?
Let’s get right into it.
CRX, Spring, JCR API, & JAX-RS
Thursday, June 5th, 2008
I have known for some time that the Spring Modules project has support for JCR integration. As it so happens, InfoQ has a nice introductory article on this very module. I have recommended to clients that future integration with CQ should revolve around direct communication with the repository itself. Well, I finally came across an opportunity to practice what I preach.
So I was asked to refine an existing piece of functionality where a separate application needed access to the content from CQ as XML. Naturally the CQ approach is to create a Servlet to start at a particular page and iterate through its children building the necessary XML. Then add a new selector to an existing template that uses this Servlet. The result was as follows.
/content/mysite/products.html (existing)
/content/mysite/products.data.xml (new)
One has to keep in mind that this products page does not contain the content for all of the products. Rather it acts like a placeholder for many nested product pages. So, this is why the Servlet would end up iterating through children of its starting page. Of course, the CQ search API could also have been used to retrieve the products. This would be much more efficient. However, this XML would contain much more than just the product content. It would contain additional content related to products that resides in referenced pages. So, even if you used to the CQ search API you would still have to then retrieve the ‘Page’ instance for each handle returned. Then for each ‘Page’ instance you would have to fetch the related ‘Page’ instances too. The search API is a little awkward though. While it may be more efficient, I can see that it was more natural to simply iterate through the children.
Within the Servlet, it would appear that the CQ approach is to use the PageToXML class provided by Day. So, each ‘Page’ was converted to XML. The resulting string was then written directly to the Servlet response.
The problem with this approach is that it is inefficient, difficult to maintain as the code is quite convoluted, and if the CQ Publish application is down the content is not available.
To refine this functionality I came up with a small list of goals.
1. Retrieve the content directly from the repository and bypass CQ.
2. Provide a true RESTful service, and not a ‘mock’ one.
3. Use a Java/XML binding framework.
Pages
Calendar
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||