loading table of contents...

Studio Developer Manual / Version 2310

Table Of Contents Design Principle: HTML First

An important design decision for data-processing — like for transformation of CoreMedia Rich Text 1.0 — is to stick to the design principle HTML first.

Sticking to this principle lowers the barriers (or even removes them) for plugins as provided by CKEditor 5 to handle the received data. So, CoreMedia may have decided to stick to represent links as xlink:href attribute in data view. Then we would be forced to define an upcast from data view to model, which follows the same rules as defined in Link plugin provided by CKEditor 5 regarding the src attribute. This again would have increased maintenance costs when applying CKEditor 5 updates.

Thus, if you introduce similar mappings, it is recommended to find the best representation in the data view, which can be handled by standard CKEditor 5 plugins.

The concept is also important to understand, when integrating plugins provided by CKEditor 5. They do not know of the received data (here: CoreMedia Rich Text 1.0) but only of the representation in data view.


  • General HTML Support: To register known elements or attributes, which are not necessarily supported by explicit plugins, you may want to register them via General HTML Support. This ensures, they are not removed when loaded from the server as they are considered unknown. The elements and attributes to register here, are those from data view. So, if you add an attribute to headings, you will register this for <h1> rather than <p> (its representation in CoreMedia Rich Text 1.0).

  • Styles: Same applies to the Styles feature. If you register styles to be applied to headings, you will register them for their representations in data view rather than in CoreMedia Rich Text 1.0 data.

What is second?

If HTML is first, the obvious question is: What is second? Some answers to this question may help you to design your customized processing of data retrieved from the server.

Second is data-consistency

Thus, if any data from the server cannot be retained, there must be another way to represent them in the various layers. See some examples:

  • Embedded Media: For images backed by content BLOB properties we need the src attribute of the <img> element to load the BLOB data from Studio server. In this case, we have to remember the original value of xlink:href which denotes the content and property to read the BLOB from. The question is, how to handle attributes like xlink:show and xlink:role available for images as well as for anchors.

  • Augmented Data for Differencing: Augmenting elements and attributes exist for difference highlighting retrieved from the server (see: Section, “Differencing Plugin”).

Possible Solutions

There are various design approaches you may choose from. Here is a short summary of the approaches used in context of the Section, “Rich Text Plugin” which may help you to design similar approaches:

  • For xlink:href of the <img> element, the original value is stored as data-xlink-href on data-processing, thus for data view. For editing downcast the attribute is ignored, thus it is only kept in the model layer. Instead, it controls filling the src attribute with a corresponding BLOB value.

    Thus, HTML data attributes are used to retain data and possibly even strip them in editing downcast.

  • For xlink:role and xlink:show the data attribute solution for the <img> element is used, as there is no alternative attribute in HTML. Thus, images will have data-xlink-role and data-xlink-show as attributes.

    Different to that, xlink:role and xlink:show map to the target attribute for <a> elements, as they are slightly related. A good mapping guarantees, that pasted HTML from external resources is kept at best effort. So, target="_blank" is mapped to xlink:show="new".

    For a complete overview of mapping approaches, see Section, “Link Plugins” and the contained LinkTarget plugin.

  • Sometimes, like in differencing augmentation, the corresponding elements and attributes are just forwarded with xdiff: namespace directly from data over data view and model up to the editing view.

    In addition, an artificial element xdiff:br was introduced to help on CSS styling to highlight added or removed newlines.

As you see, designing a good mapping requires, among other things, to respect data consistency as well as editing experience and good compatibility to pasted HTML data.

Search Results

Table Of Contents

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.