Ideas for the Widget API

[amitev]

Hello, we have requirements to support forms and dynamic components (yes, I know that the purpose of the editor is just to allow content editing :-)) inside the editable content (we are currently using CKEditor 4).

We have several custom widgets that are implemented as AngularJS components that get compiled when the widget is initialized by the editor. We faced the following issues on the way:

• CKEditor doesn't allow interaction with form fields inside the editable content - the editor doesn't allow focusing, copy, paste, etc. within from fields. As suggested by @Reinmar we are stopping the event propagation for all of the known events so the editor doesn't know what happens inside the widget. This works but have its drawbacks. I.e the user cannot select and copy text from the content of the widget, the widget isn't properly styled on focus.
• The widget have dynamic content controlled by the angular component and we store widget-specific configurations as serialized json in attribute. However the undo manager doesn't know about this and the undo/redo functionality gets broken sometime.
• Widget drag and drop destroys the widget and recreates it on the new position - this causes some problems with dynamic components as they have to be recreated. This requires additional computation power for large widgets (we have data tables inside widgets).
• We have created a custom plugin that allows creation of layouts based on twbs. However the editor doesn’t allow drag and drop in the last column sometimes.

Here you can see a sample widget with an angularjs component inside.

I would be really glad to see CKEditor 5 supporting my use cases. Please let me know if you need more information.

[pjasiun]

I like your example very much.

In fact since the beginning of the CKEditor 5 development we keep such cases in mind. For instance it would be great to change image to the "editing mode" and change the source of it in-place, without any dialog. I like to imagine even the animation that you can "flip" the image to the other side and edit properties there.

This is why the view, from the very beginning, let you add elements which have no corresponding model elements but are handled by other controllers. These might be some visual markers (for instance yellow background when you search, and in fact we already work to make such changes as simple as possible https://github.com/ckeditor/ckeditor5-engine/issues/484), but also independent parts of the document, like the form.

I think it is too early to talk about details, we do not work on widgets yet, but your cases are very useful and I will keep them in mind when we will do.

[amitev]

Our widgets support edit/preview modes but this is done currently in the angularjs components. It will be great if CKEditor also supports such features. When in preview mode, we currently bootstrap the editor in readonly mode in order to have the widgets initialized (and thus compiled by angular).

[Reinmar]

I'd like to add that it's very likely that there will be no need to create a widgets concept at all, because the engine has or will have most of the features of CKE4's widgets built in.

The biggest problem when we worked on widgets in CKEditor 4 was that this feature was developed so late. It requires deep integration with dozens of mechanisms all around the code. So in CKEditor 5 we're keeping these use cases in mind from the first day. Also, CKEditor 5's engine is incomparably more powerful than what was possible in CKEditor 4, which didn't have a separation of model and view.

All this means that from day one CKEditor 5 allows for things which weren't possible in CKEditor 4. You can check some of our proof of concepts on CKEditor 5 hackathon repo.

As for specific cases that you mentioned:

• There will be much more control over how feature listen to native events. The engine's view is an interface which lets you plug your own observers which later fire our custom events on the view itself. So your feature will be able to block them at the right moment. Since all existing features will listen on those synthetic events, they won't be triggered at all if an event is blocked.
• The undo manager works on model operations level in CKEditor 5. So undo is not concerned at all with how the stuff gets rendered by converters (controllers which transform model to view).
• As for drag and drop and widget reloading, this is a more tricky topic because those things need to be integrated with native clipboard. We'll have to yet understand how this may and should work and I'm not sure whether we'll be able to improve this that much.
• As for drag and drop in last column – hard to say whether this is an editor issue or browser issue. But that's not related to widgets.

[amitev]

@Reinmar A widget concept would allow you to create elements with predefined content, editable/non-editable zones, DnD, etc. which is very useful.

[Reinmar]

I think that it's inevitable that some tools will be created – sth. like widget factory. But it will be just a util, using the features which are available in the engine. Not a whole, huge system itself (in CKE4 the widget plugin is very big).

[fredck]

I think we'll understand this later. There is a chance that the concept of widgets will still exist at high level (@amitev), to name document elements that have a complex view representation during editing. Still this is supposed to be merely a concept by than as the tools to create them are already present under different low level concepts (@Reinmar).

[Reinmar]

Cleaning up old discussions. See https://github.com/ckeditor/ckeditor5-design/issues/186.