You can either keep a reference to ctx2 and call persist() after the flush() of the editor driver; or you can cast the RequestContext returned by flush() and call persist on it (the returned RequestContext is the one you passed as an argument to edit(), so it's == ctx2).
Or you can enqueue the persist() method on the ctx2 *before* calling edit(), so that you just have to fire() after the flush(). It goes like this: - ctx2.edit(myProxy) → now ctx2 tracks changes to myProxy (actually, it only created a mutable version of it –and only one RequestContext can have a mutable version of a proxy at a given time–, the changes are not "tracked", the RequestContext only does a diff between the mutable proxy and the immutable proxy at the time of the fire()). You can call edit() several times for the same proxy on the same RequestContext, it will always return the same mutable proxy (you can also call edit() with the mutable proxy, it'll be returned without error). RequestFactoryEditorDriver#edit automatically calls RequestContext#edit so you don't have to do it yourself if you don't need it. - ctx2.persist(myProxy).with(paths).to(someReceiver) → enqueues into ctx2 an invocation to the "persist" method with argument "myProxy" (can be a mutable proxy or immutable proxy, edit() will automatically be called at the time of the fire()) and paths "paths", when the context will be fired and the server responds, the Receiver will be called with the invocation result (the return value on the server, converted to a client type). - ctx2.fire() → gets the changes of the edit()ed proxies and serializes them (this is known as "operations"), gets the enqueued invocations and serializes them, sends the batch to the server. On the server, operations are processed (calls find() on your domain object –or the locator– and then calls the setters from the operations), then invocations (each invocation can fail independently of the others; after each successful invocation, the "paths" sent from the client for the invocation are resolved on the return value), and then return values and server failures are serialized to be sent back to the client (in addition, for each domain object seen as input or output, their "liveness" is checked and can result in a "PERSIST operation" or "DELETE operation" serialized for the entity, then the versions are compared to the one sent by the client and if they don't match an "UPDATE operation" is serialized for the entity). On the client-side, proxies are deserialized, operations are turned into EntityChangeEvents, and then for each invocation, depending on their success on the server, the onSuccess or onFailure of the attached Receiver is called. There are of course additional steps for onConstraintViolations and "global failure", but you get the general idea: when you persist() a proxy, it doesn't take a snapshot of its state, it only enqueues an invocation; the state will be taken at the time you call fire(), not before. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/bWYhohNWCz0J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
