Gwt 是否可以将EntityProxy附加到另一个RequestContext？我应该吗？

我有一个编辑实体的小表单。我使用RequestContext的一个实例创建该实体，然后在“保存”按钮的处理程序中，我尝试使用RequestContext的另一个实例来持久化它

尝试持久化失败，出现预期的异常：

java.lang.IllegalArgumentException:尝试编辑以前由另一个RequestContext编辑的EntityProxy

问题是:

• 是否可以将EntityProxy附加到另一个RequestContext
• 这样做对吗？或者我应该重用一个请求上下文来保存它 作为我们班的财产

---

重用现有的。如果你需要一个新的，合并它们。但是做一个新的是没有意义的。原因如下：
当您对服务器进行RF调用时，它会经历几个步骤，因为它主要针对如何读取和持久化实体以及它们所处理的各种值属性
• 创建或检索任何要处理的实例
• 将setter应用于这些实例（新的或现有的），并验证它们
• 运行服务调用，可以作为在实体上调用的方法、静态调用或服务调用
这三个步骤是按此顺序完成的，以确保对象在到达服务调用时被修改并传递给服务调用是有意义的。以后的调用（即其他请求）可能不需要对相同的实体进行相同的更改，如果需要，则需要自己进行更改
给定的

RequestContext

包含所有这些内容。如果有两个请求，其中一个表示要调用的setter（来自表单的编辑），另一个表示服务请求，则触发一个表示仅调用setter，而不调用服务调用来保存它，而触发另一个表示仅调用save而不调用服务调用
在一个

EntityProxy

被标记为由一个请求上下文编辑后，尝试在另一个请求上下文中使用它几乎肯定是一个错误，因此会引发您看到的异常。使用现有类型，或者使用

RequestContext.append

（如果需要）切换到新的

RequestContext

类型以实际运行保存操作

---

RequestFactory不是RPC-您的对象不仅仅是Java Bean，而是某些服务器对象的代理（无论是

EntityProxy

还是

ValueProxy

），请求用于异步操作它们。
Colin，您能告诉我，在使用上下文持久化实体之后，是否应该对上下文做些什么吗？它在第一次调用时工作，但所有后续调用都会导致抛出

java.lang.IllegalStateException:请求已在进行中

。一个

RequestContext

是一种一次性构建器。一旦你

fire（）

d它，它就不再可用了（除非有违反约束的情况或者请求由于网络错误而失败）。唯一可以重用它的情况是它在服务器上以可以重新发送的方式失败-我相信唯一的情况是发生验证错误，因此调用了setter，但服务调用不是。这些setter应该能够在用户纠正其验证问题后再次调用，然后进行调用。