Question

当我使用以下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是否不检查架构，还是我误解了架构应该做什么？

Answer 1

您是对的– Writer不会检查架构。

原因是它是一个非常低级的工具，它实现了对模型执行原子操作的方式（好吧，我躺在这里，因为下面有一个更低的级别，由operations表示）本身，但这是受保护的API）。无论如何，作者是相当低级的。

现在，当您实现命令或任何其他功能时，可能需要执行多项操作才能进行所有必要的更改。同时（在这些原子操作之间）的状态可能不正确。作者必须允许。

例如，您需要将<foo>从<$root>移至<bar>，并（同时）将其重命名为<oof>。但是，该架构定义了<oof>和<$root>中的<foo>中不允许<bar>。如果编写者愿意检查架构，则无论rename和move操作的顺序如何，它都会抱怨。

但是，可以说这可以通过在change()块的末尾检查模式来解决（它像事务一样工作-状态必须在末尾是正确的）。实际上，我们在该块的末尾plan to strip disallowed attributes。

但是有问题：

在提交交易后如何修复内容？不可能实施一种合理的启发式方法，该方法不会从用户的角度破坏内容。
在协作更改期间，该模型可能会失效。运营转换虽然由我们以非常丰富的形式（使用11种类型的运营而不是基数3的形式）实施，但可以确保解决冲突和最终实现一致性，但不能保证模型的有效性。

因此，我们选择使用更具表现力和灵活性的post fixers处理每种情况下的此类情况。此外，我们将检查架构的职责移到了功能上。他们可以先做出更好的决策，然后再进行更改。

为什么我可以在不修改架构的情况下将自定义元素插入ckeditor

1 个答案: