MVC

---

---

⚠⚠ ⚠⚠ ⚠⚠

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.

---

---

The CKEditor 5 architecture will be based on the MVC model. This will bring a huge impact in terms of code reorganization, but it is a necessary move to make it more manageable, testable, stable and extensible.

MVCVM = Model + View + Controller + View Model

CKEditor is based into a variation of MVC, the MVCVM model, composed by the following layers:

• Model: holds the whole business logic (at domain level). It’s everything. It contains all the data used for the UI/UX aspects of the application, but it has no idea how it is going to be consumed. It’s the only layer that has nothing to do with UI.

• View: its the drawing layer of the application UI. It render interface components based on data available in the View Model. It has no idea where this data comes from. It may contain logic exclusively related to UI components defined by itself.

• Controller: puts all the layers together and execute the application. Based on Models, feeds Views and View Models and handles UX interactions in the View, making the necessary updates to the Model and vice-versa.

• View Model: contains a certain format of data which is dedicated to a particular View. It doesn’t know where the data comes from or where it’ll be used This data can come straight from the Model or it can be derived from it. It can be even created by the Controller exclusively, without any Model interaction.

In practice, the addition of View Model makes the Controller code much cleaner and organized and helps on testing as dumb View Models can be used to tests Views and View Model reactions can be checked even when Views are not available.

The “Model”

We had troubles earlier to defined what is the Model in CKEditor. That’s because we automatically translate it to “data” when thinking about it and the “data” produced by CKEditor is the HTML outputted by it. So we got stuck on just that.

But that way of thinking was focused in the end-user point of view. Instead, CKEditor is a component to be used by developers to bring their solutions to life. There are also plugin developers that want “data”, just like us when implementing the default plugins. So there is a lot of stuff that we can expose, like commands, configurations, instances, selection, etc. So the editor API is the business logic to be exposed in our Model.

Then, based on that Model, implementations can bring controllers and views that will transform that data into UIs in all their different variations. In fact, that separation will make it much simpler to bring different UI solutions for the very same editor. Read this as Desktop and Mobiles, for example.

The Model's State

The following is a gross representation of the objects we should find in the CKEditor 5 Model's state:

• CKEDITOR (non part of the Model)
  • Editors List (Instances)
    • Editor
      • Configurations
      • Commands List
      • Plugins List
      • Language Dictionary
      • Editable
      • Selection
      • Data
      • Data Processor

The above may not be complete and it doesn't include the attributes exposed by the model. One should expect to find there everything that makes sense in terms of data, from the editor name to configuration options.

To understand better what we could have in the model state, imagine that it should be theoretically possible to serialize the state (e.g. as JSON data) and recreate the very same editor based on it.

MVC API

CKEditor provides its own MVC API, to be used inside core and plugins. Such API could be based on third-party libraries, like Backbone, but we need much less than what these solutions include. So we'll not reinvent the wheel, but simply making a new wheel model that works best for our car :)

The heart of the API are the Model (mvc/model) and View (mvc/view) classes, which provide the basic infrastructure to implement MVC-based classes, offering observable and data-biding features.

@TODO: Summarize the MVC API here, linking to the proper API documentation once available.