Universal Editor Architecture

Learn about the architecture of the Universal Editor and how data flows between its services and layers.

Architecture Building Blocks

The Universal Editor is made up of four essential building blocks that interact to allow content authors to edit any aspect of any content in any implementation in order to deliver exceptional experiences, increase content velocity, and provide a state-of-the-art developer experience.

1. Editors
2. Remote App
3. API Layer
4. Persistence Layer

This document outlines each of these building blocks and how they exchange data.

Editors

• Universal Editor - The Universal Editor uses an instrumented DOM to allow in-place editing of content. Please see the document Attributes and Types for details regarding the necessary metadata. See the document Getting Started with the Universal Editor in AEM for an example of the instrumentation in AEM.
• Properties Rail - Some properties of components can be not edited in-context, e.g. rotation time of a carousel or which accordion tab shall be always opened or closed. To allow for editing of such component information, a form-based editor is provided in the side rail of the editor.

Remote App

To make an app in-context editable within the Universal Editor, the DOM must be instrumented. The remote app must render certain attributes in the DOM. Please see the document Attributes and Types for details regarding the necessary metadata. See the document Getting Started with the Universal Editor in AEM for an example of the instrumentation in AEM.

The Universal Editor strives for a minimal SDK, thus the instrumentation is the responsibility of the remote app implementation.

API Layer

• Content Data - For the Universal Editor, neither the source systems of the content data nor the way it is consumed is important. It is only important to define and provide the required attributes using in-context editable data.
• Persisting Data - For each editable data there is a URN identifier. This URN is used to route the persistence to the right system and resource.

Persistence Layer

• Content Fragment Model - To support the rail for editing Content Fragment properties, the Content Fragment Editor, and form-based editors, models per component and content fragment are required.
• Content - Content can be stored anywhere, such as in AEM, Magento, etc.

Universal Editor Service and Backend System Dispatch

The Universal Editor dispatches all content changes to a centralized service called the Universal Editor Service. This service, running on Adobe I/O Runtime, loads plugins available in the Extension Registry based on the provided URN. The plugin is responsible for communicating to the backend and returning a unified response.

Rendering Pipelines

Server Side Rendering

Static Site Generation

Client Side Rendering

Additional Resources

To learn more about the Universal Editor, see these documents.

• Universal Editor Introduction - Learn how the Universal Editor enables editing any aspect of any content in any implementation in order to deliver exceptional experiences, increase content velocity, and provide a state-of-the-art developer experience.
• Authoring Content with the Universal Editor - Learn how easy and intuitive it is for content authors to create content using the Universal Editor.
• Publishing Content with the Universal Editor - Learn how the Universal Visual Editor publishes content and how your apps can handle the published content.
• Getting Started with the Universal Editor in AEM - Learn how to get access to the Universal Editor and how to start instrumenting your first AEM app to use it.
• Attributes and Types - Learn about the data attributes and types that the Universal Editor requires.
• Universal Editor Authentication - Learn how the Universal Editor authenticates.

Business.Adobe.com resources