GWT request factory: Please help explain a complete end-to-end WriteOperation.DELETE scenario?

Question

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:

1. 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) ?

1. 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?

Answer 1

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:

Entities that can be no longer retrieved ...

What it really means is that isLive has returned false, and isLive's implementation defaults to doing a get by the ID and checking for a non-null result.