Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#11472 closed New Feature (invalid)

Detection & initialisation of widgets in foreign injection of HTML

Reported by: xmo Owned by:
Priority: Normal Milestone:
Component: UI : Widgets Version:
Keywords: Cc:

Description

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".

Change History (5)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by Piotrek Koszuliński

Status: newpending

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.

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by Piotrek Koszuliński

Resolution: invalid
Status: pendingclosed

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.

comment:5 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy