Touch UI: migrating to Adobe Experience Manager’s new look

Javier Furio
The Telegraph Engineering
5 min readJan 14, 2019
Changing face of AEM: the old and new dialog boxes side by side

At Telegraph Engineering, we are always facing new challenges. One of our main tools at the newspaper is AEM; this is an Adobe product based on several open source projects (Apache Sling, Apache Felix, Apache Jackrabbit), combining them in order to offer a nice content manager experience.

Over the years we have used AEM to generate a considerable number of Classic UI dialogs and currently, as Adobe is planning to deprecate the Classic UI in April 2018, we are in the process of migrating toward the new standard user interface, called Touch UI.

What is Touch UI?

Touch UI is the new standard user interface for AEM, designed to work in both touch and desktop devices. It was introduced by Adobe for the first time in 2013 (AEM 5.6) and is based on the following level structure:

  • Touch UI → (uses) Granite UI foundational building blocks.
  • Granite UI: On top of Coral UI, provides to Touch UI foundational building blocks (Coral UI widgets wrapped into sling components) to build the dialogs and user interfaces consoles.
  • Coral UI: library of touch-first web components for creating beautiful experiences.

Let’s have a look and compare these two user interfaces to have a better understanding:

  • JCR structure overview: A content repository is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation…
  • Here we can see the difference way of persist the nodes between classic and touch ui:
  • Architecture flow overview:

Classic UI (client-side render approach): The browser gets dialog properties from the jcr by making a backend call and renders all fields.

Touch UI (server-side render approach): Each component is defined by the sling:ResourceType. AEM will localise the dialog and the associated components and it will be rendered in the server side outputting the HTML result to the client.

Can the classic UI dialogs co-exist with the new Touch UI interface?

The answer is yes; AEM provides a backward-compatible mechanism. If we are in the new Touch UI user interface and we haven’t defined the new “cq:dialog” in the jcr, it’s possible to render the classic “dialog” thanks to this feature.

How does it work?

What it does is open the classic one inside an iframe wrapped with the new Touch UI look-and-feel popup. This is what it looks like:

Touch UI validation overview:

  • In order to validate our forms, Touch UI will use the new foundation-validation interface. It will capture the form submit event on the client side (javascript validation) and it will detect if there are some errors in the form, skipping the request to the server if needed.
interface FoundationValidationValidator {
selector: string;
selector: (index: number, element: Element) => boolean;
validate: (element: Element) => string;
show: (element: Element, message: string, ctx: FoundationValidationValidatorContext) => void;
clear: (element: Element, ctx: FoundationValidationValidatorContext) => void;
}
  • foundation-validation itself is not performing the actual validation. In order to add a validator, we need to make use of “foundation.validation.validator” interface, implement the needed behaviour and register it making use of the foundation-registry interface.
interface FoundationRegistry {
register(name: string, config: any): void;
get(name: string): any[];
}
  • The recommended way to do this registration is by using the AdaptTo interface.

SAMPLE:

Requirement: ArticleBodyText input text should have a minimum length of 10 characters.

  • Our component makes use of the following clientlib folder, which uses the property “myapp-minLenght” defined in _cq_dialog/context.xml (cq:dialog/articleBodyText):

References:

Javier Furio is a software engineer at The Telegraph. You can follow him on Twitter

--

--