GWT 请求工厂：请帮助解释一个完整的端到端 WriteOperation.DELETE 场景？

Question

最近看了很多gwt request factory的例子，还是没找到全图：

GWT 请求工厂的最佳选择是 CRUD（创建/读取/更新/删除）。话虽如此：

1. 即使在“更新”情况下，我也不清楚谁负责触发 EntityProxyChange（事件）

我在某处（忘记在哪里）读到客户端请求工厂保留了它“看到”的 EntityProxy 的本地缓存，并且，如果它“看到”一个新缓存，那么它会触发一个 EntityProxyChange（事件）

这是否意味着，如果我的“updatePerson()”方法返回一个（新更新的）PersonProxy，那么本地客户端请求工厂基础设施是否“看到”这个新更新的人（即，凭借其更新的 versionId）然后它会自动触发 EntityProxyChange (Event) 吗？

1. 在“删除”的情况下，假设我在请求上下文中创建了一个名为“deletePerson()”的函数，我了解请求如何到达服务器并且可能会这样做，例如删除实体的 SQL DELETE，但是，谁负责触发带有 WriteOperation=DELETE 的 EntityProxyChange（事件）？这些事件会在服务器端触发吗？客户端？

我查看了 listwidget 示例 (http://code.google.com/p/listwidget)，但是，在“itemlist”删除时，它有点“作弊”，只需对整个列表进行暴力刷新（尽管我确实理解该细节不一定是listwidget首先试图说明的）；我本来希望看到一个 EntityProxyChange (Event) 处理程序来侦听 WriteOperation.DELETE 事件，然后只从 ListDataProvider 中删除该实体。

ServiceLayer/ServiceLayerDecorator.isLive() 是否会影响这些因素？

Answer 1

见http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryMovingParts#Flow

客户端不保留缓存（虽然在一年前的早期迭代中可能是这种情况，但在非里程碑版本中从未如此），服务器端负责“触发”事件（您将在 JSON 响应负载中看到它们）。

当上面引用的 wiki 页面说：

无法再检索的实体...

真正的意思是isLive已经返回false，而isLive的实现默认是通过ID做get并检查非空结果。