Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#11186 closed Bug (fixed)

A way to block upcasting given element to a widget

Reported by: Piotrek Koszuliński Owned by: Piotrek Koszuliński
Priority: Normal Milestone: CKEditor 4.3.2
Component: UI : Widgets Version: 4.3
Keywords: Cc:

Description (last modified by Piotrek Koszuliński)

TC: there's a plugin which prints out an image e.g. as a preview of something. If image2 is loaded, it will upcast that image, so DOM structure will be changed, what perhaps will create a conflict between image2 and theoretical plugin.

Theoretically, plugin can be rewritten to make use of widgets (because if it prints out something different than it is, it is a case for widgets). But in real life developers will need to make that plugin compatible with 4.3+ without so much effort, so an easy way to prevent upcasting on certain elements will be useful.

  1. First option is an attribute, but it's not yet present in data (and in fact shouldn't be at all), so it would have to be added while loading data. That means during processing them, but upcasting is done before htmlDataProcessor#dataFilter is applied, so one would have to do an additional iteration over entire structure. Not good.
  1. Then, we have the possibility to overwrite image2's upcast method. This solves the problem in quite clean way, but it's not perfect. Theoretical plugin has to know about image2 and still may be broken by other widgets about which it doesn't know.
  1. Better than overwriting specific widget would be to block upcasting globally. So we may add mechanism like:
editor.widgets.addUpcastMethod( function( el ) { ... } );

Returning false would block upcasting on that element. Returning other values could modify upcasting in a different way, but I don't have a clear concept yet.

Other possible method names: onUpcast, addUpcastCallback.

Change History (8)

comment:1 Changed 10 years ago by Piotrek Koszuliński

Description: modified (diff)

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

Milestone: CKEditor 4.3.2
Status: newconfirmed

After a discussion with fredck we decided to choose the 3rd option. Proposed method name was addUpcastCallback. We should avoid using CKEDITOR.event here because of unnecessary overhead. That event would be fired for every element, so the waste would be huge.

comment:3 Changed 10 years ago by Piotrek Koszuliński

Owner: set to Piotrek Koszuliński
Status: confirmedassigned

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

Status: assignedreview

Pushed t/11186 on dev and tests.

comment:5 Changed 10 years ago by Olek Nowodziński

Status: reviewreview_passed

I pushed a minor commit to the test branch. Everything's fine except the name of the method. addUpcastMethod suggests that it's possible to extend the upcasting logic, while what we do here is a basic filtering (pre-filtering, actually). addUpcastFilter would be more convenient IMO.

This "empty" return should be return false, right?

Last edited 10 years ago by Olek Nowodziński (previous) (diff)

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

The method is named addUpcastCallback. It does not explain what this callback can do, because we don't know this yet. Currently we have only one use case for it - rejecting elements, but we may find more in the future. That's why I chose generic "Callback" rather than "Filter".

​This "empty" return should be return false, right?

No. It should be empty. That's because we don't want to block iterating over ancestors of that rejected element. E.g. in this case:

<figure class="special"><img></figure>

Someone may want to block upcasting entire special figure, but have inline image inside it.

comment:7 Changed 10 years ago by Piotrek Koszuliński

Resolution: fixed
Status: review_passedclosed

Fixed on master with git:4d1bf91 on dev and bce4ab1 on tests.

comment:8 Changed 8 years ago by Jakub Ś

#14426 was marked as duplicate.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy