如何回滚knockout验证错误？

本文介绍了如何回滚knockout验证错误？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 我使用实验框架6.0的敲除验证2.0.3，并获得意外的验证错误。这是我的工作流程：

Step1：（按预期工作）使用添加对话框创建一个新实体，并尝试保存新实体。显示验证错误，因为缺少某些属性。这是想要的行为。用户取消对话框，并调用 unitofwork.rollback（）来撤销新实体的创建。

Step2：打开同一类型的现有实体的编辑对话框。尝试保存它原样。 => 再次显示步骤1中的验证错误！

如何在步骤1之后清除验证错误？

如果我只执行step2，保存操作很正常。

在相关的stackoverflow问题中建议使用

错误.showAllMessages（假）;

这没有解决我的问题。

相关问题：

• 敲除验证的清除错误

• 清除或重置敲门验证validatedObservable？

• 淘汰验证 - 如何显示错误消息

解决方案

>

validation.group（checkedEntity，{deep：true}）;

完整的对象树还考虑了被检查实体的 entityAspect 。 entityAspect连接到实体管理器。该实体管理器包含该实体的旧状态。

完整的周期是：

fooInstance => entityAspect => entityManager => entityGroupMap => Foo :. .. => _entities => 旧实体实例

因此，我基本上有两个选项：

• 不要使用{deep：true}
• 确保在回滚后，实体管理器不再包含旧实体： li>

entityManager.rejectChanges（）;

strong> entityManager.clear（）;

I use knockout validation 2.0.3 with entity framework 6.0 and get unexpected validation errors. Here is my workflow:

Step1: (works as expected) Create a new entity with an add-dialog and try to save the new entity. Validation errors are shown because some properties are missing. This is the wanted behavior. The user cancels the dialog and I call unitofwork.rollback() to undo the creation of the new entity.

Step2: Open the edit dialog for an existing entity of the same type. Try to save it as it is. => The validation errors from step 1 are shown again!

How can I clear the validation errors after step1?

If I only execute step2, the save action works just fine.

In a related stackoverflow question It was suggested to use

errors.showAllMessages(false);

That did not resolve my issue.

Related questions:

• Clear error on Knockout-Validation

• Clearing or resetting a knockout validation validatedObservable?

• Knockout Validation - How to show error messages

解决方案

For the validation I used

validation.group(checkedEntity, { deep: true });

The full object tree also considers the entityAspect of the checked entity. The entityAspect is connected to the entity manager. And that entity manager contains the old state of the entity.

The complete cycle is:

fooInstance => entityAspect => entityManager => entityGroupMap => Foo:... => _entities => old entity instance

Therefore I basically have two options:

• Do not use { deep: true }
• Make sure that after the rollback the entity manager does not contain the old entity any more:

entityManager.rejectChanges();

entityManager.clear();