Conversion from simple model to complex view (slot conversion)

[jodator]

Some nested widgets might have a structure that does not map 1:1 all elements inside.

(View)                                 (Model)
div.widget                           -> widget
    div.wrapper
        div.inner-wrapper
            div.widget-title
                div.sub-editable     ->    widgetTitle
            div.widget-body
                div.sub-editable     ->    widgetBody

Similar case is with current widgets that maps <figure> from the view to <image> or <table> element in the model. So the mapping is not element to element but rather view widget wrapper to model element.

This complicates stuff as to override some parts of such widget conversion requires deeper understanding of the feature. For image it is hard IMO but for tables might be hard as hell for outsiders.

The second part is to showcase how to map view element editable to element in the model so the selection and automatic conversion of children will work out-of-the-box. In such example one would rather convert div.widget-title but map the div.sub-editable to widgetTitle in the model.

[Reinmar]

I've made a PoC of what I call a "slot conversion", when we can control where children of a specific model element are being inserted in the view: https://github.com/ckeditor/ckeditor5-core/tree/poc-slot-conversion (updated version in monorepo: https://github.com/ckeditor/ckeditor5/tree/poc/slot-conversion)

(View)                                   (Model)
div.container                        <-> container
    div.slot
        foo                          <->     foo
        bar                          <->     bar

This is a bit different scenario than what you described, because in what you showed @jodator widgetTitle gets converted to a specific place and so does widgetBody. However, I'd try to think how to generalise both approaches and document both. I've been often asked about both of them and perhaps they share more common aspects than it initially seems.

[Reinmar]

BTW, this is labeled with type:docs, but I think we could also propose an API for that. That'd be much better.

[Reinmar]

Interestingly, the slot conversion that I made a PoC of in #1589 (comment) break widget type around feature. Since the model element is mapped to the slot, the WTA feature does not recognise the widget element as here it gets the slot element instead.

That could probably be fixed in WTA itself because I don't know why it gets the view element from the model element and not the other way around, but in general, playing with mappings may lead to such issues.

After implementing a couple such widgets I see two things that we should make easier:

• Defining a converter that inserts all children of the element being converted into a given container element of the created view structure.
  • Example: You need two nested containers, one within the other to represent a single model element. And children of that model element should be converted into the nested container.
• Defining a converter that inserts the view element into a different than default location in the already existing view.
  • Example: block widget like https://ckeditor.com/docs/ckeditor5/latest/framework/guides/tutorials/implementing-a-block-widget.html but which title and content editable elements should be wrapped with some more markup (that'd normally be generated by the container's converter).

[tomalec]

As for a freshman, without any knowledge of CKE5 converters, the problem looks like Shadow DOM content distribution.

There was even a proposal from Google for an imperative distribution API:

• https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md
• https://groups.google.com/a/chromium.org/g/blink-dev/c/TNYIAu5E_M4/m/1i7LME9WCwAJ?pli=1

Maybe we can get some inspiration and naming the native world, to make CKE-specific things easier to understand.

BTW, why don't we use the actual shadow DOM?

[jodator]

Cross-linking table case: #8138 (comment).

[niegowski]

Outdated DUP #10294