-
Notifications
You must be signed in to change notification settings - Fork 12
Modularity and Namespacing
Status: Working Draft
The CKEditor 5 architecture is based on two important aspects which, as a matter of fact, are contrasting: modularity and namespacing.
While previous versions of CKEditor were developed in a modular way, there was no clear model in use to implement such modularity. With CKEditor 5 instead, we’re making the whole API implementation based on AMD patterns and best practices.
Modularity helps on having a clearer code base to be maintained, where modules have more independence and isolation. In fact, the loosely coupling aspect of modules is one of the most important features of this model.
Additionally, AMD is becoming a standard nowadays, so we’ll be exposing the API with a module definition. The main API entry point is in fact the "ckeditor" module.
When it comes to the AMD framework used by CKEditor we have a few options:
- A custom system is implemented under the "ckeditor" module.
- A third-party solution is used, like RequireJS.
- A third-party solution is masked inside the CKEditor API, under the "ckeditor" module.
The very first part of the CKEditor Library coding will be, in fact, dedicated to identify the best approach for this.
Taking in consideration the "act as a library" position of CKEditor, and being it essentially a component to be integrated inside applications, it must provide a clear and powerful API. Additionally, there should be no requirements for third-party software (like jQuery or RequireJS). Therefore, CKEditor is based on namespacing as its API entry point.
CKEditor creates one and only one global namespace variable that holds the whole API, named CKEDITOR. This variable is essentially the main "ckeditor" module, which therefore is used to reach most of the exposed API.