۶Ƶ

DocumentationAEM 6.5User Guide

Migration to the Touch UI migration-to-the-touch-ui

Last update: Wed Apr 17 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

CREATED FOR:

  • Developer

Starting with version 6.0, ۶Ƶ Experience Manager (AEM) introduced a new user interface referred to as the touch-enabled UI (also known simply as the touch UI). It is aligned to the ۶Ƶ Experience Cloud and to the overall ۶Ƶ user interface guidelines. This has become the standard UI in AEM with the legacy, desktop-oriented interface referred to as the classic UI.

If you have been using AEM with classic UI, take action to migrate your instance. This page is intended to act as a springboard by providing links to individual resources.

NOTE
Such a migration project may have significant impact on your instance. See Managing Projects - Best Practices for recommended guidelines.

The Basics the-basics

When migrating, be aware of the following major differences between the classic and touch UI:

Classic UI
Touch-Enabled UI
Is described in the JCR repository as a structure of nodes. Every node that represents an element of the UI is called an ExtJS widget and rendered on the client-side by ExtJS.
Also described in the JCR repository as a structure of nodes. However, in this case, every node refers to a Sling resource type (Sling component), that is in charge of its rendering. So the UI is (basically) rendered server-side.

sling:resourceType

  • not used

sling:resourceType

  • used
  • for example
    cq/gui/components/authoring/dialog

Dialog nodes:

  • Name: dialog
  • jcr:primaryType: cq:Dialog

Dialog nodes:

  • Name: cq:dialog
  • jcr:primaryType: nt:unstructured

JavaScript location:

  • Imperative parts are directly embedded using listeners or managed in clientlibs.

JavaScript location:

  • Imperative parts cannot be embedded in dialog definition; separation of responsibilities.

Event handling:

  • Dialog widgets directly reference JavaScript code.

Event handling:

  • JavaScript observes dialog events.

Rendering done by the client:

  • Client dynamically creates the UI components.
  • Client requests (Pull) component definition (as JSON) from server.

Rendering done by the server:

  • Client requests pages together with the related UI.
  • The server sends (Push) the UI as HTML documents; using Coral UI components.

In other words, migrating a section of your UI from the classic UI to the touch UI means to port an ExtJS widget to a Sling component. To ease this, the touch UI is based on the Granite UI framework, which already provides some Sling components for the UI (referred to as Granite UI components).

Before you start, check the status and related recommendations:

The basics of developing the touch UI provides a solid basis:

Migrating Page Authoring migrating-page-authoring

Dialogs are a major factor when migrating your components:

Migrating Consoles migrating-consoles

You can also customize the consoles:

Although not directly related to a migration to the touch UI, there are related issues that are worth considering at the same time, as they are also recommended practice:

NOTE
See also Developing - Best Practices.

Further Resources further-resources

For full information on developing AEM see the collection of resources under:

CAUTION
AEM Modernization Tools are a community effort and are not supported or warranted by ۶Ƶ.
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2