Every developer have experienced a situation where they are working with AEM multiple AEM components, where Touch UI dialogues consist of a common richtext Granite UI component configuration cq/gui/components/authoring/dialog/richtext. When I mention common richtext Granite UI component, I mean there are multiple AEM components that will have the richtext Granite UI component as one of it’s input fields, where only the “links*” and “format*” richtext features are enabled, as an example.
Enabling only the “links*” and “format*” richtext features, we catch ourselves repeating lines of code by copying and pasting the entire block of code for all of our Touch UI dialogues that require the richtext requirement. This works, but this is Write Everything Twice, “WET” code, and it’s not good implementation; this can be improved. What happens if there is a new requirement where the authors would like a new capability to the richtext field? Will we have to edit multiple dialogues? (like editing 20 component’s dialogues) The short answer is Yes. With this “WET” implementation, you must edit every single component’s dialogue configuration.
How can we do this better? How keep our code Don’t Repeat Yourself (DRY)?
Utilising the Granite UI component, granite/ui/components/coral/foundation/include, we are able to refer to common Granite UI component configurations in the JCR (that we are going to set up). Now changing the richtext configuration in one place will provide TouchUI dialogue changes to all 20+ components; see diagram below.
In this section, code will be shared on how this configuration can be applied to your own AEM implementation. The example produced will be a summary of the diagram from above.
We will be creating a common richtext Granite UI configuration which will be referenced by a example component.