Posts tagged "custom component"

April 24, 2017

AEM Multi-Site Tips & Tricks Preview – IMMERSE 2017

We are excited to share another post in the AEM Rockstar Tips & Tricks Guest Blog series! This Tips & Tricks preview is from Brett Birschbach, an AEM Certified Architect and AEM Rockstar semi-finalist who will be a session presenter at Adobe’s global virtual developer conference, IMMERSE May 15th – 19th 2017. Brett will detail his Tips & Tricks in a follow-up post after IMMERSE. Brett’s session will be on Tuesday, May 16, 1:15-2:15 PM Central (11:15-12:15 PDT).

Brett is the Adobe Marketing Cloud Solutions Architect for HS2 Solutions, a digital transformation company based in Chicago. He is a hands-on problem solver with experience leading large multinational, multi-site platform projects.  Brett led the development of the new Shared Component Properties feature in the open source ACS AEM Commons library. For more from Brett, visit his Github: HitmanInWis.

Multi-site platforms are the norm in a mature Adobe Experience Manager installation. However, most implementations, in true Agile fashion, start as a single site and then expand to support multiple. Suppose your client is the NFL and it wants to put all 32 teams on the same AEM platform. We all know that launching 32 team sites on day one is A Bad Idea, so likely you are going to start with just one site as a proof of concept.  However, Agile tends to tempt a lot of us in this situation into thinking that “I’ll just code for this one site now, and worry about multi-site support and code structures on the second site when I actually need them.”  YAGNI, right?  Except…you ARE going to need it.  Pretending you are building a single site when you know the platform is going to support multiple, thinking only in the present instead of taking a step back and getting the full picture, is a great way to paint yourself into a corner.


Man painted into corner

Image by Ali Moussa, HS2 Solutions

Coding a multi-site platform beginning with single-site patterns, we are faced with technical debt in making the transition to multi-site – technical debt that often never gets fully paid.  Let’s be real, clients want to see sites #2 through #32 launched as quickly as possible after site #1 is launched.  After all, that’s the vision you cast them – that they would easily be able to create and manage all their sites on a single platform using the same components and authoring techniques as the first site.  To the client, having a single working site seems like it should account for 80% of the total work, so the rest of the sites should be a snap.  You know as well as I do that the urgency to turn out these sites means that much of the technical debt accrued early in the project will be worked around and put off until resolution on a proverbial someday, never to be repaid.  Bad decisions made when creating the first site often linger on for as long as the platform lives.

Image by Ali Moussa, HS2 Solutions

But it doesn’t have to be this way.  Structuring your code base for multi-site success isn’t that hard to do, it’s just easier not to do it (which is why we end up in this situation).  But what if you had a step-by-step guide?  What if you could leverage the experience of peers who have already done it well?  This stuff isn’t rocket science, and the principles don’t change much from project to project.  No sense wasting your time trying to come up with all the techniques on your own.  Wouldn’t you rather be doing the fun stuff like banging out a sweet, interactive Schedule component for authors to drop onto those 32 NFL team sites?  Of course, you would!  That’s why I encourage you to attend the “Multi-Sites: Setting your Codebase Up for Success” session at Adobe IMMERSE 2017.


Why should you attend?

  • Adobe IMMERSE is the premier AEM developer conference of the year, focusing on the technical audience.  If you’re not already registered, sign up using the link above!
  • I’ll be covering Basic, Advanced, and Overachiever techniques, 15 in all, using the NFL example above (modified to HFL, to avoid any grumbling from the lawyers).
  • The techniques come from a successful, international, multi-site platform implementation hosting a dozen brand and corporate sites, so they are tried and proven.
  • Every example (yes, every last one) will be demonstrated by real code that you can download, look at, and play with in order to gain a true understanding that only code can give.

Disclaimer: Being a Green Bay native (and therefore huge Packers aficionado) I *may* take the liberty to take a few jabs at our archrivals in Chicago…don’t take it personally 🙂




2:53 PM Permalink
December 1, 2011

Custom Component: FAQ (Accordion) Paragraph System

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.


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.


5:03 PM Permalink

Custom Component: FAQ component (Simple)

Basic Requirements:

  • Authors can drag and drop the FAQ Component from the CQ5 sidekick to a paragraph system.
  • In the dialog of the FAQ Component, authors can type in multiple question-and-answer pairs.
  • The FAQ Component uses jQuery UI to render the questions and answers inside an Accordion. Clicking on the questions would expand the answers.


  • Multi Composite Fields widget should be registered.
  • jQuery UI Library added as a clientlibs in the system.


Simple FAQ Component Demo

High Level Overview on creating this custom component:

  1. In CRXDE, create a new component (cq:Component) of FAQ. Set the following properties:
  • allowedParents - */parsys
  • sling:resourceSuperType - foundation/components/parsys
  • Create a cq:Dialog with the following structure:
    • dialog [cq:Dialog] > items [cq:TabPanel] > items [cq:WidgetCollection] >
      faqPanel [cq:Panel] > items [cq:WidgetCollection] > faqEntries[cq:Widget] >
      fieldConfigs [cq:WidgetCollection]
  • The faqEntries [cq:Widget] node would be using xtype of the Multi Composite Fields.
  • Inside the fieldConfigs [cq:WidgetCollection] node, create the necessary fields to capture the question and answer pair. For example:
    • answer [cq:Widget] with xtype = richtext
    • question [cq:Widget] with xtype = textfield
  • Specify the appropriate listeners to refresh the page so that modification to the FAQ component would trigger (or re-trigger) the jQueryUI Accordion.
  • Modify the component JSP file so that the generated markup of question-answer pairs would fulfill jQueryUI’s markup requirement.
  • Finally, create a cq:ClientLibraryFolder for the FAQ Component. It should contain a javascript file to render the Accordion.
  • Sample of the component:

    1:24 AM Permalink
    • Authors

    • Archives

    • Developer Resources