All about CQ

In this blog post I would like to talk about a more complicated version of the FAQ Component, which was previously blogged here.

The Simple FAQ Component is fairly limited when it comes to adding new features into the FAQ Answers (richtext xtype). Customers might sometimes want to be able to add non-textual components into the answers fields. For example, they might want to:

Add an image to an answer.

Embed a video in an answer.

Add a table, list of children pages, or even a site map.

To support any of the above, the Simple FAQ Component would require major modification which would impact existing content nodes (A major No No!). Now, let’s combine all of the requirements from the Simple FAQ Component with the features listed above, and consider the following single use case:

User can drag and drop multiple components from the sidekick into a region on a page, and the components (movable) inside the region would be rendered inside a jQuery UI Accordion.

This use case sounds very much like the CQ5 out-of-the-box Paragraph System, where components can be drag-and-drop’ed and be moved around. The missing piece here is the presentation of the components in an expandable/collapsible grouping system.

Applying to the FAQ concept, let me introduce an Accordion Paragraph System. Take a look at the demo below and we’ll dive into the overview.

Demo:

Overview of implementation:

The FAQ Paragraph System actually consists of multiple components. The following steps are grouped by individual components, and for best practice these components are placed inside the same folder (faqparsys). Please take a look at the diagram below for the overall structure of the parsys:

clientlibs [cq:ClientLibraryFolder]:

containing javascript to trigger the jQuery UI Accordion.

faqparsys [cq:Component]:

Much like the OOTB parsys component. The only difference is the rendering of children components in Accordion order.

faqparsys would loop through all children components. If component is of type faquestion [cq:Component], then it would render the faquestion as an Accordion header. Otherwise components (before the next faquestion component) are grouped as Accordion content.

At the end of the faqparsys render, the faqparsysend component is included to signify the end of the paragraph system (for better user experience).

The faqparsys is set to refresh the page on the following listeners so the jQuery UI Accordion would re-trigger and display correctly:

afterdelete

afteredit

afterinsert

faquestion [cq:Component]:

Simple extension of the OOTB Title Component, so that the type “faquestion” can be identified by the faqparsys.

faqparsysend [cq:Component]:

This component renders the editbar layout. It is used to signify the end of the paragraph system.

Sample of the finished component:

Enjoy! Again, part of the source-code can be made available upon request. Please email me directly at ochoy@adobe.

–EDIT 2011/12/08– Due to the number of requests I’m getting regarding the source code, please kindly understand that there will be a slight delay in my responses.