当我使用以下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 是不检查架构，还是我误解了架构应该做什么？
你是对的 -Writer不检查架构。
原因是它是一个相当低级的工具，它实现了在模型上执行原子操作的方式(好吧，我躺在这里，因为下面有一个更低的级别，由操作本身表示，但这是一个受保护的 API(。无论如何，作者是相当低级的。
现在，当您实现命令或任何其他功能时，您可能需要执行多个操作来执行所有必要的更改。同时(在这些原子操作之间(的状态可能不正确。作者必须允许这样做。
例如，您需要将<foo>从<$root>移动到<bar>，并(同时(将其重命名为<oof>。但是模式定义了<oof>在<$root>中是不允许的，在<bar>中是不允许<foo>的。如果编写器检查架构，则无论rename和move操作的顺序如何，它都会抱怨。
但是，假设我们可以通过检查change()块末尾的模式来解决这个问题(它的工作方式类似于事务 - 状态在结束时需要正确(。事实上，我们计划在该块的末尾去除不允许的属性。
但是，存在一些问题：
- 提交交易后如何修复内容？从用户的角度来看，不可能实现不会破坏内容的合理启发式方法。
- 在协作更改期间，模型可能会变得无效。运营转型虽然由我们以非常丰富的形式实现(使用 11 种类型的操作而不是基础 3 种(，但可确保冲突解决和最终一致性，但不能确保模型的有效性。
因此，我们选择根据案例处理这种情况，使用更具表现力和灵活性的后期修复器。此外，我们将检查架构的责任转移到功能上。在做出改变之前，他们可以先验地做出更好的决定。