最近查看了很多 gwt 请求工厂示例，但仍然无法找到完整的情况：
GWT 请求工厂的最佳点是 CRUD（创建/读取/更新/删除）。话虽如此：
- 即使在“更新”情况下，我也不清楚谁负责触发 EntityProxyChange （事件）
我在某处读到（忘记在哪里）客户端请求工厂保留了 EntityProxy 的本地缓存'seen'，并且，如果它'看到'一个新的，那么它会触发 EntityProxyChange （事件），
这是否意味着，如果我的“updatePerson()”方法返回一个（新更新的）PersonProxy，那么本地客户端会执行此操作吗？请求工厂基础设施“看到”这个新更新的人（即，凭借其更新的 versionId），然后它会自动触发 EntityProxyChange （事件）吗？
- 在“删除”情况下，假设我在请求上下文中创建了一个名为“deletePerson()”的函数，我了解请求如何到达服务器，并且可以执行例如 SQL DELETE 来删除实体，但是，谁负责触发 EntityProxyChange (Event) w/WriteOperation=DELETE ？这些事件会在服务器端触发吗？客户端？
我查看了 listwidget 示例 (http://code.google.com/p/listwidget< /a>），但是，在删除“itemlist”时，它只是通过对整个列表进行强力刷新来进行“作弊”（尽管我确实明白该细节不一定是 listwidget 在第一个中试图说明的内容） 地方）;我本希望看到一个 EntityProxyChange （事件）处理程序，它侦听 WriteOperation.DELETE 事件，然后仅从 ListDataProvider 中删除该实体。
ServiceLayer/ServiceLayerDecorator.isLive() 是否会影响其中任何一个因素？
Been looking at a lot of gwt request factory examples lately but still can't quite find the complete picture:
GWT request factory's sweet spot is CRUD (create/read/update/delete). Having said that:
- Even in the "update" case, it is not clear to me who is responsible for firing a EntityProxyChange (Event)
I read somewhere (forget where) that the client side request factory keeps a local cache of EntityProxy that it has 'seen', and, if it 'sees' a new one then it fires a EntityProxyChange (Event)
does that mean that, if my "updatePerson()" method returns a (newly updated) PersonProxy, then does the local client side request factory infrastructure 'see' this newly updated person (i.e., by virtue of its updated versionId) and then does it automatically fire a EntityProxyChange (Event) ?
- In the "delete" case, say I create a function called "deletePerson()" in my request context, I understand how the request arrives at the server and one might do, e.g., a SQL DELETE to delete the entity, but, who is responsible for firing a EntityProxyChange (Event) w/WriteOperation=DELETE ? do these events get fired at the server side? the client side?
I've had a look at the listwidget example (http://code.google.com/p/listwidget), but, on a 'itemlist' delete, it kinda 'cheats' by just doing a brute force refresh of the entire list (though I do understand that that detail is not necessarily what listwidget is trying to illustrate in the first place); I would have expected to see a EntityProxyChange (Event) handler that listens for WriteOperation.DELETE events and then would just remove just that entity from the ListDataProvider.
Does ServiceLayer/ServiceLayerDecorator.isLive() factor into any of this?
发布评论
评论（1）
请参阅 http://code.google.com/p/google- web-toolkit/wiki/RequestFactoryMovingParts#Flow
客户端不保留缓存（在一年前的早期迭代中可能是这种情况，但在非里程碑版本中从未出现过这种情况） ， 和服务器端负责“触发”事件（您将在 JSON 响应负载中看到它们）。
当上面引用的维基页面说：
它的真正含义是
isLive已返回false，并且isLive的实现默认执行以下操作aget通过 ID 并检查非空结果。See http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryMovingParts#Flow
The client-side doesn't keep a cache (that was probably the case in the early iterations a year ago though, but has never been the case in non-milestones releases), and the server-side is responsible for "firing" the events (you'll see them in the JSON response payload).
When the wiki page referenced above says:
What it really means is that
isLivehas returnedfalse, andisLive's implementation defaults to doing agetby the ID and checking for a non-null result.