You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl;dr: UIElement children should not be stored in the view.
So we decided to introduce UIElement (https://github.com/ckeditor/ckeditor5-engine/issues/788) and we decided to disable adding children to it in the very first version to keep things simple at the beginning. Now the question is how children of the UI element should be handled.
The first option seems to be natural: UIElement can have children in the view like any other element. The profit is that they will be handled like any other children. The problem is that they will be handled like any other childer ;) For instance TreeWalker will enter there and the developer needs to ensure not to thread text in the UIElement like a text in the content. Also, these children should be never moved out of this UIElement, should not accept selection and have no model representation. More I think about them more I feel that view does not care about the UIElement children.
So now the second option appear: what if the UIElement is always empty in the view, but have the whole structure hidden. Developer mark it only to be re-rendered, if needed. The renderer asks the UIElement for its children and inserts then into the DOM element. Thanks to it the element will be always simple in the view but may have a very complex internal structure in the DOM. It can also handle events (click, drag) internally what will be also transparent for the view, observers, and converters.
I think that the second approach will be more flexible: we will be able to implement any UI component and do not care how it will affect the view.
To make the API consistent, every view node could have a render() method which will create DOM element/elements. Now its renderer who create a DOM node based on the view, but moving it out of the renderer is something I was thinking about for a long time.
The text was updated successfully, but these errors were encountered:
In the F2F talk, we agreed that the first step should be to add the render() method only to the UIElement. It should be used by the DOMCoverter. At the same time, observers have to be updated to handle events on the UIElement children properly. In particular, it should not be possible to put the selection inside the UIElement (it should be moved before or after it). Click event should be fired on the view.UIElement.
Feature: UIElement has it's own render method used by DomConverter and can create DOM children. Improved integration with observers and other view elements. Closes #799.
mlewand
transferred this issue from ckeditor/ckeditor5-engine
Oct 9, 2019
tl;dr: UIElement children should not be stored in the view.
So we decided to introduce
UIElement
(https://github.com/ckeditor/ckeditor5-engine/issues/788) and we decided to disable adding children to it in the very first version to keep things simple at the beginning. Now the question is how children of the UI element should be handled.The first option seems to be natural:
UIElement
can have children in the view like any other element. The profit is that they will be handled like any other children. The problem is that they will be handled like any other childer ;) For instanceTreeWalker
will enter there and the developer needs to ensure not to thread text in theUIElement
like a text in the content. Also, these children should be never moved out of thisUIElement
, should not accept selection and have no model representation. More I think about them more I feel that view does not care about theUIElement
children.So now the second option appear: what if the
UIElement
is always empty in the view, but have the whole structure hidden. Developer mark it only to be re-rendered, if needed. The renderer asks theUIElement
for its children and inserts then into the DOM element. Thanks to it the element will be always simple in the view but may have a very complex internal structure in the DOM. It can also handle events (click, drag) internally what will be also transparent for the view, observers, and converters.I think that the second approach will be more flexible: we will be able to implement any UI component and do not care how it will affect the view.
To make the API consistent, every view node could have a
render()
method which will create DOM element/elements. Now its renderer who create a DOM node based on the view, but moving it out of the renderer is something I was thinking about for a long time.The text was updated successfully, but these errors were encountered: