Почему я могу вставить пользовательский элемент в ckeditor без изменения схемы - PullRequest
Новая
       15

Почему я могу вставить пользовательский элемент в ckeditor без изменения схемы

0 голосов
/ 04 сентября 2018

Когда я использую следующий код JavaScript, пользовательский узел вставляется в модель. Но я не понимаю, почему это работает, когда этот тип (mtnote) не был зарегистрирован в схеме. 

    model.change(writer => {
        const noteElement=writer.createElement('mtnote',{ 'noteText': 'Hello first note' } );
                const insertNotePos=model.document.selection.getFirstPosition();
                writer.append(noteElement,insertNotePos);
});

Я знаю, что узел вставлен, потому что я могу видеть его, когда перебираю модель, и если я добавляю editor.conversion.for ('downcast'), я могу понизить элемент mtnote до любого элемента представления, который мне нужен .

Так что writer.append не проверяет схему или я неправильно понял, что должна делать схема?

1 Ответ

0 голосов
/ 04 сентября 2018

Вы правы - Writer не проверяет схему.

Причина этого в том, что это довольно низкоуровневый инструмент, который реализует способ выполнения атомарных операций над моделью (хорошо, я лежу здесь, потому что есть еще более низкий уровень, представленный операциями сами, но это защищенный API). Во всяком случае, писатель довольно низкого уровня.

Теперь, когда вы реализуете команду или любую другую функцию, вам может потребоваться выполнить несколько операций, чтобы выполнить все необходимые изменения. Между тем состояние (между этими атомарными операциями) может быть неправильным. Автор должен это допустить.

Например, вам нужно переместить <foo> с <$root> на <bar> и (одновременно) переименовать его в <oof>. Но схема определяет, что <oof> недопустимо в <$root> и <foo> в <bar>. Если автор проверяет схему, он будет жаловаться независимо от порядка операций rename и move.

Но скажем, это мы могли бы решить, проверив схему в конце блока change() (он работает как транзакция - состояние должно быть правильным в конце). Фактически, мы планируем удалить запрещенные атрибуты в конце этих блоков.

Однако есть проблемы:

  • Как исправить содержимое после совершения транзакции? Невозможно реализовать разумную эвристику, которая не нарушала бы контент с точки зрения пользователя.
  • Модель может стать недействительной во время совместных изменений. Операционная трансформация, хотя и реализована нами в очень богатой форме (с 11 типами операций вместо базовых 3), обеспечивает разрешение конфликтов и возможную согласованность, но не достоверность модели.

Поэтому мы решили обрабатывать такие ситуации для каждого случая, используя более выразительные и гибкие post fixers . Кроме того, мы перенесли ответственность за проверку схемы на функции. Они могут принимать гораздо лучшие решения, прежде чем вносить изменения.

...