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

Question

最近看了很多gwt请求工厂的例子，但仍然无法找到完整的图片：

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

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

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

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

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

我已经查看了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响应有效负载中看到它们）。

当上面提到的维基页面显示：

  

无法再检索的实体......

真正意味着isLive已返回false，而isLive的实现默认为通过ID执行get并检查非null结果