you mean keep a reference to ctx2 and call persist on it after the flush ,
becouse persist requires the proxy, i think i finally got the bit about
queing, and i'm going for the edit-persist sequence, and flush-fire (which
won't make much sense readability wise), but then again, neither is most of
rf related code anyway.
now the real issue here is the validation handling, i understand the proper
way is to catch the onConstraintViolations here:
DRIVER.setConstraintViolations(violations);
final List<EditorError> errors = DRIVER.getErrors();
for (final EditorError editorError : errors) {
final Object userData = editorError.getUserData();
final Object value = editorError.getValue();
System.out.println(userData);
System.out.println(value);
}
(because getting the errors has only after the call on flush made it.
but this still doesn't make much sense in regards to the client side
validation of gwt (the "experimental" one), if i got it right, i would have
to duplicate my validation annotations on to the getter of the entityProxy,
and manually call the validate command on it, before i even use the flush,
but then i'm back to the fact i don't have an updated entityProxy to
validate against ..
On Wed, Nov 30, 2011 at 11:39 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
> 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.
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
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.
