Detection & initialisation of widgets in foreign injection of HTML

[xmo]

I'm currently working on a system where the RTE is only part of the whole, and thus some tools interacting with the RTE are (mostly) independent from and unaware of the RTE.

For the most part things work great, but an issue I've encountered is when one of these separate components adds a DOM subtree without the RTE's root *and* that subtree contains potential widgets.

As far as I understand the code, part of the widget processing pipeline (the detection of widget candidates via upcast calls and the creation of the wrapper) is performed during data processing, and the activation of the detected & wrapped widgets is a second step (performed via repository#initOnAll(). As a result, to get widgets to be detected in foreign-injected HTML my process is currently:

el.outerHTML = editor.dataProcessor.toHtml(el.outerHTML);

editor.widgets.initOnAll();

This *seems* to work correctly, but

1. I'm uncertain this is the right way to do it (if there's any such thing as a "the right way" to do this at the moment)
2. if any of the foreign (aka non-cke-aware) components added non-DOM data (e.g. event handlers, attributes on DOM nodes) it would be lost by the serialization-processing-deserialization (currently not the case for me)

Thus it would be nice if there were a blessed API through which one could tell the widgets plugin/repository "here's a DOM subtree (DOM element), find out if there's any widget in it and initialise them in-place".

[xmo]

s/with the RTE/with the RTE's content/, "foreign" components manipulate the DOM tree within the editor's #element without being aware that the RTE is there.

[Piotrek Koszuliński]

Do you mean that some parts of your system interacts with the editable's content directly, without using any "input" methods like editor#insertHtml or editable#insertHtmlIntoRanges (to skip selection)?

I would say that this is a bad practice in a first place. There's a pretty strong separation for what's inside editable and what's in data. By interacting with editable's content directly not only widgets will not be initialized but also other structures may be lost/malformed - e.g. links, images, iframes, etc. I understand that it will require more effort to make system aware of editor, but otherwise many issues may occur.

However, if I understand you incorrectly, and by interacting with RTE's content you meant using the input methods of editor, then there should be no problems with upcasting widgets. All methods that work on data (this excludes insertElement only) passes data through data processor which handles upcasting and wrapping (yes, you understood the code correctly).

BTW. It's worth mentioning that since upcasting is done on data (and there's no chance to perform it on real DOM), if you really need to interact with editor directly, then using dataProcessor the way you did and then using widgets.initOnAll it is the only possible way.

[xmo]

Do you mean that some parts of your system interacts with the editable's content directly, without using any "input" methods like editor#insertHtml or editable#insertHtmlIntoRanges (to skip selection)?

Correct, the rest of the system is unaware of and independent from ckeditor, and thus does not use its APIs (currently anyway).

I would say that this is a bad practice in a first place.

Yes, from the RTE's point of view I can definitely see that.

I understand that it will require more effort to make system aware of editor, but otherwise many issues may occur.

That works both ways though, e.g. because of cke's data processing, the metadata added by a component (event handlers, or references kept to specific DOM nodes) is not conserved across injection.

[Piotrek Koszuliński]

These are limitations, I agree. But I cannot imagine how it could work differently. Doing data processing and filtering on real DOM would... be a mess :D. So it simply has to work this way, creating certain limitations. Or rather not limitations, but obstacles, because this all can be overcome, although it requires effort.

PS. It's an interesting topic, but I think that without a possible positive ending, so I'm closing this ticket.

[xmo]

It's an interesting topic, but I think that without a possible positive ending, so I'm closing this ticket.

No problem, thanks for the insight/discussion.