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

Когда я использую следующий код 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 не проверяет схему, или я неправильно понял, что должна делать схема?


javascript ckeditor ckeditor5
person MTilsted    schedule 03.09.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

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

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

person Reinmar    schedule 04.09.2018