Ckeditor5: How to make the data processor configurable

[Reinmar]

Currently, the data processor is defined by the ClassicEditor constructor: https://github.com/ckeditor/ckeditor5-editor-classic/blob/39ec2895c43b0a1eefbb8e7be0b07993468ed7d8/src/classic.js#L37

This means that if someone wanted to use the ClassicEditor with a different DP he/she would need to override it, which is ugly and means that two DPs are in the bundle (small problem because HtmlDP will be in each bundle anyway, because clipboard needs it).

However, overriding a DP isn't that simple, because you need to write a plugin which will do this. 10LOC when you want to change one little thing... So it made me think that perhaps DPs should have accompanying plugins that you can simply enable in the editor. Such a plugin, when initialised, will set the editor.data.processor property.

This means that each DP will have a plugin that enables it. This sounds a bit like an overkill, but seems to be the easiest option for the end-developers.

[Reinmar]

I posted an example how to enable a data processor of your choice now: https://github.com/ckeditor/ckeditor5/issues/417#issuecomment-293198175.

[Reinmar]

If everyone is ok with this method, we can just add such a plugin to the ckeditor5-markdown-gfm package and that's it.

[Reinmar]

cc @pjasiun @szymonkups @oleq

[oleq]

Is config.data.processor = () => new HtmlDataProcessor() or config.data.processor = new HtmlDataProcessor() an option here? Because we allow functions as config values and this seems to be the best DX, I suppose.

[Reinmar]

Yeah, I've been thinking whether this isn't even more straightforward. From one perspective it is, but from the other, it adds a config option (which, for some reason, sounds bad to me :D).

But, perhaps it will be just simpler. Less files in pkgs like ckeditor5-markdown-gfm will be easier to understand.

Besides, one can always write a plugin just like I showed: https://github.com/ckeditor/ckeditor5/issues/417#issuecomment-293198175. So, I'd go with:

config.data.processor = new HtmlDataProcessor();

All ok?

[pjasiun]

I'm not sure about it. On the one hand, the configuration option is nice and simple. On the other, I feel that only small parts of the logic should be changed by the configuration, bigger should be changed by plugins. And this seems to be a big change in the logic (even if it's just one line of code to enable). But that's true that the boundary between what should be a plugin and what should be a config is subjective.

One more argument to have DP as a plugin is that some plugins may require it, for instance, some Markdown formatting plugin may require MarkdownDP plugin.

[oleq]

On the other, I feel that only small parts of the logic should be changed by the configuration, bigger should be changed by plugins.

A good point. OTOH...

One more argument to have DP as a plugin is that some plugins may require it, for instance, some Markdown formatting plugin may require MarkdownDP plugin.

how different it would be from import HtmlDataProcessor from ...? I mean, what advantage has the Plugin approach in this context?

[fredck]

I would not go with a configuration option here.

The DP is one of the things that defined the kind of editor as a whole. You're not playing around saying, this time I want HTML, then Markdown, then BBCode, all within the same editor. I should be able to just build the editor with the DP already defined into it.

[Reinmar]

I would not go with a configuration option here.

The DP is one of the things that defined the kind of editor as a whole. You're not playing around saying, this time I want HTML, then Markdown, then BBCode, all within the same editor. I should be able to just build the editor with the DP already defined into it.

Good points. Actually, that was the initial idea why not making this a config option but they kinda left my mind. That, plus the fact that it's not always simple to get access to the DP you want to enable if you use a build.

However, it won't be a problem to allow configuring such things through the config options in the future because, when defining builds, we made sure that they define the built-in configs in a normal way:

• https://github.com/ckeditor/ckeditor5-build-classic/blob/master/config-editor.js
• https://github.com/ckeditor/ckeditor5-build-classic/blob/b938f617f5a847614af1c811e3eea50aee8c7c25/ckeditor.js#L43

(I mention this because the initial idea was much worse and didn't support it.)

Still, do you mean, @fredck to force people to define their own editor when they want to change DP or that it can be done by enabling a plugin?

[Reinmar]

One more argument to have DP as a plugin is that some plugins may require it, for instance, some Markdown formatting plugin may require MarkdownDP plugin.

Haha. Thanks guys for reminding me that :D Your memory works better than mine because that was also the reason why it was meant to be a plugin. We could, for instance, imagine the MD preset and that preset will be able to easily turn on the MD processor plugin (OTOH, it can also override editor.data.processor manually, since a preset is also a plugin :D.

Another thing is that MD processor plugin may itself want to change some settings (e.g. configure the schema). Being a plugin, it will have all the rights to do so.

how different it would be from import HtmlDataProcessor from ...? I mean, what advantage has the Plugin approach in this context?

Plugin may execute code and plugin may have other dependencies. Also, you can disable or hot load some plugins. When you just import and manually initialise stuff then you don't have these mechanisms.

[jodator]

Simple, but effective way was introduced in Markdown plugin: #6007. It boils down to:

config.data.processor = MarkdownDataProcessor( ... );