Skip to content

Architecture Overview

Jump to bottom Edit New page
Piotrek Koszuliński edited this page Apr 20, 2018 · 12 revisions

⚠⚠ ⚠⚠ ⚠⚠

This wiki served in the early days of CKEditor 5 development and can be severely outdated.

Refer to the official CKEditor 5 documentation for up-to-date information.




Unlike version 4, CKEditor 5 will not be made of a single codebase anymore. The revised architecture has been divided into the following building blocks, each one fulfilling a different scope:

  • CKEditor Library: the heart of the project. A generic library for editing.
  • CKEditor UI Library: a reusable set of UI elements targeted to editing solutions.
  • Features: modules bringing features to CKEditor, based on the library API.
  • Creators: modules implementing editor bootstrapping logic.
  • Implementations: different editing solutions ready to be used, making use of the above building blocks.

At the same time, the project will also be split physically into multiple npm packages, each fulfilling one or more of the above roles. A package can contain multiple JavaScript modules implementing features, utils, ui components and other building blocks. Packages can also contain themes. As mentioned earlier, it's possible that a single package falls into more than one logical category. However, it's recommended that each package serves just one role.

The CKEditor 5 package names should be prefixed with ckeditor5-* and they should fall into one of the below categories:

It is recommended that each package is kept in a separate Git repository. The main Git repositories are described in the Repositories article and match official packages 1:1.

Plugins

"Plugin" is a common name for JavaScript modules which extend the editor in some way. Those modules must export classes which inherit from the Plugin class. Features, themes, creators are plugins.

In other words:

  • the project consists of multiple npm packages,
  • each package can contain multiple JavaScript modules,
  • some of these modules can be plugins,
  • each plugin is of one type: feature, theme, creator.

Read more about plugins.

The CKEditor Library

The CKEditor library is a general use API designed for building editing solutions inside browsers. It contains all the tools needed to create a stable and full-featured editing experience.

The library is made of the following main building blocks:

  • Core: the basic elements of the API.
  • Editing: the elements that enable and control the editing experience.
  • Data: data input, output, manipulation and filtering.
  • Utils: generic API utils.
  • Bindings: integration with external code and everything about gluing things together into editing implementations.

Important note: While being a generic solution, the CKEditor Library is designed and optimized for CKEditor implementations, so third-party requirements may not be taken into consideration.

The CKEditor UI Library

(tl;dr) The default UI library used by CKEditor, which can be replaced by third-party libraries.

CKEditor 5 will introduce a UI abstraction level that will permit to have different UI libraries attached to the same editing solution. For instance, if an editor based on jQuery UI is to be designed, it should be possible to take the existing editing implementations and replace their existing UI components with jQuery UI elements.

While this flexibility is awesome, still a non-third-party solution needs to be in place, to avoid dependencies on specific projects. Therefore, the CKEditor UI Library will be introduced, including the default UI used by CKEditor.

While CKEditor will be a general purpose library, the CKEditor UI Library will be, in any case, optimized exclusively for the CKEditor needs. Therefore, even if it could be used by other projects, there is little chance that we’ll bring features and enhancements to it, if such features will have no use for the CKEditor project purposes.

Examples of UI elements available in the CKEditor UI Library:

  • Toolbar
  • Button
  • Drop-down list
  • Menu
  • Menu button
  • Dialog window
  • Dialog window fields
  • etc.

The main editor structure styling should be a part of the library as well.

Mobile

There is a good chance that the CKEditor UI Library will have its mobile variant which will include UI elements dedicated to mobile interfaces. This aspect will be better understood as soon as we conclude the design of CKEditor for Mobile.

Themes

When it comes to themes, it is quite dependent on the UI library in use. Therefore, the entire concept of themes will be delivered by the UI library itself, which will define if and how themes can be managed.

Feature Modules

(tl;dr) Features are modules bringing all kinds of editing functionality. In the first stage we may expect features dedicated to create good quality web content.

While we are in any case performing a significant review in terms of architecture and design of the project, feature modules will keep the conceptual role of plugins in CKEditor 4: they will bring features to CKEditor. In fact, the CKEditor Library alone has little use without additional feature modules (and other building blocks of CKEditor, of course).

Unlike we did when creating version 4, this time we’ll not port all available plugins to CKEditor 5. Especially in the way we did it, without touching their code too much, leaving it mostly "as is". Instead, we’ll analyse which features to port and review them from scratch, especially in terms of design.

This means that we may have some features simplified, ported partially or even not ported at all.

What to Expect

The list of features to be ported to CKEditor 5 is still to be defined. We’ll definitely be focused on the most wanted features and on those that can enhance the quality of content created. We can also expect new features to come.

In fact quality of content is the key here and we must keep in mind that CKEditor has an important role. We must support the effort made out there to create good content for the Web and the future. This may be difficult in some situations, because many times people simply don’t have enough knowledge about content management and pretend to have things in a different way.

It is way too easy to introduce features that are attractive to the eyes of end users, but very bad for the quality of the content. For example, features that are dedicated to text formatting, like margins, borders, colors, fonts, alignments, etc. Those are the kinds of features that should be avoided and therefore they’ll not be our priority, at least in the first stage.

In any case, let’s also keep in mind that still a good part of our users want to have formatting features (no matter what). Additionally, CKEditor can be built to be a “word processor”, where no web content rules apply. Therefore the possibility of having quality formatting features also made available is not out of question.

Creators

The creators are pieces of code which can be used by developer to quickly bootstrap a specific kind of an editor. For example, the ckeditor5-creator-classic will create an editor with a static toolbar and editable inside and iframe. It will use existing building blocks and glue them together.

Implementations

(tl;dr) Implementations are the final products delivered to end-developers, an extension to CKEditor 4 presets. Implementations use previously described building blocks to created ready-to-use solutions. There must be cross-compatibility for data produced with different implementations on the same configurations/systems.

Implementations represent the final product of the entire CKEditor project. They make use of the previously described building blocks (The CKEditor Core Library, UI Library, Creators and Feature Modules), bringing to light the editing solutions to be used by developers inside their applications.

The following are some sample implementation solutions:

  • The normal editing box we offer today (classic editor).
  • Floating toolbar for inline editing (inline editor).
  • One line field editing.
  • Top toolbar for whole page editing.
  • Dedicated UI for mobile editing.
  • Paged-like document editing (e.g. A4 pages).
  • UI based on external libraries, like YUI and jQuery UI.
  • Component for editing to be used in mobile or desktop apps.

Cross-Implementation Compatibility

There are situations when the same application may make use of more than one implementation of CKEditor. For example, it may use the classic editor for desktop and the mobile editor for mobiles, both accessing the same content base, which includes cross-editing of the same content on different devices (and therefore, different editor implementations).

Because of the above, special attention must be paid to the following aspects when designing editor implementations:

  • Configuration: Whenever possible, configurations should be active for different implementations, each one behaving in the most appropriate way for its goal.

  • Features: Whenever possible, features should be available cross-implementation. It’s acceptable though to have features that are not enabled in some cases.

  • Data: Even if features are disabled, data produced with a different implementation sharing the same configuration should be preserved and remain untouched. In other words, if one just loads the same data in different implementations, no data loss is noticed. It is OK to have a part of the data not editable in an implementation that is not able to edit such part.

Add a custom footer
Add a custom sidebar
Clone this wiki locally