Studio Developer Manual / Version 2301
Table Of ContentsAn 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.
Examples:
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
srcattribute of the<img>element to load the BLOB data from Studio server. In this case, we have to remember the original value ofxlink:hrefwhich denotes the content and property to read the BLOB from. The question is, how to handle attributes likexlink:showandxlink:roleavailable 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 10.1.2.2, “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 10.1.2.7, “Rich Text Plugin” which may help you to design similar approaches:
For
xlink:hrefof the<img>element, the original value is stored asdata-xlink-hrefon 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 thesrcattribute with a corresponding BLOB value.Thus, HTML data attributes are used to retain data and possibly even strip them in editing downcast.
For
xlink:roleandxlink:showthe data attribute solution for the<img>element is used, as there is no alternative attribute in HTML. Thus, images will havedata-xlink-roleanddata-xlink-showas attributes.Different to that,
xlink:roleandxlink:showmap to thetargetattribute 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 toxlink:show="new".For a complete overview of mapping approaches, see Section 10.1.2.6, “Link Plugins” and the contained
LinkTargetplugin.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:brwas 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.
