GWT: Continue editing the same object after request to server

Question

Is it possible to continue editing the same object after GWT server request?

Consider best-practices code from another question

void start() {
    // Either get p
    context1.get(..).to( new Receiver<P> { onSuccess(P resp){p = resp;} ... }).fire();
    // OR create p
    p = context2.create( P.class );
    // Then save p
    req = context2.persist(p).to( new Receiver<P>{  /* note do not use context1 */
        onViolation(...) { /*JSR 303 handler*/ };
        onFailure( error ) { /* handle */ error.getMessage() }; 
        onSuccess(X x) { /* whatever persist() returns handler */ }; } ); 
    // drive editor with p
    driver.edit( p, req);    
}

....
void onSave() {    
    // editor
    ctxt = driver.flush()  /* note ctxt == context2 */
    if ( driver.hasErrors() ) { /*JSR 303 handler*/};
    // RF
    ctxt.fire();
}

The question is, how to handle un-successful server response in the last line? (add receiver to "ctxt.fire();")

void onSave() {    
    // editor
    ctxt = driver.flush()  /* note ctxt == context2 */
    if ( driver.hasErrors() ) { /*JSR 303 handler*/};
    // RF
    ctxt.fire(new Receiver<S>{
        onSuccess() { ... how to continue editing the "p" object? ... } 
        onFailure() { ... how to continue editing the "p" object? ... } });
    });
}

For example, on save, sever does some additional validation (e.g. that value is unique). And does not accept to save it.

So, server request finishes with "onSuccess(response)" method, but object was not saved (response value may contain list of errors).

Is it possible to allow user to continue editing the unsaved, but updated on client side object and make another request to the server?

The "deadlock" that I see:

• It is not possible to reuse request context (ctxt), because "A request is already in progress" exception will be thrown.
• It is not possible to create a new context, because all modifications to the object are in the old context (so they will be lost).

Answer 1

Mutable proxies are always bound to a request context. Proxies you receive from the server, however, are frozen and not mutable. The .edit method will make a mutable clone of a frozen proxy for a given request context.

If a request couldn't be fired (connection issues, server error), the context will be re-usable and you can continue editing the proxy. Same applies if the constraints were violated. If a request was successfully fired (no matter if the server method threw an exception or not), the request context cannot be used no more and the same applies to the proxy.

Have a look at onTransportSuccess in AbstractRequestContext - this will tell you: the only cases in which you can continue using the request context are violation and general failure. So either you enforce a violation or you return (the erroneous) object to the client and continue working on it with a fresh request context (this will lead to issues with entity proxies I'm afraid since it will loose the reference state)