Request Context clear queue on method invocations when onConstraintViolation is called

[Alex Vakaloudis]

To perform save  in a view I am using RequestFactoryEditorDriver to flush any changes to a RequestContext and then I call 

save(the edited proxy).to(MyReceiver<Void>).fire();

MemberRequest s = (MemberRequest)editorDriver.flush();

MemberProxy sectorProxy = (MemberProxy)getProxy();

s.saveMember(sectorProxy).to(new MyReceiver<Void>()).fire();

MyReceiver has a onConstraintViolation method which displays violations generated in the server. I am using my own  ServiceLayerDecorator.validate() to check for any business-related constraints.

To this point it works fine. However when after more than one attempts the user "fixes" all violations and the entity reaches the service, the save method is invoked multiple times (as many attempts it took to pass validation). I understand that  this is because the request context is queuing all method invocations and by calling onConstraintViolation. this queue is not cleared and this leads to multiple calls to the server.

My question is how/where to clear the request context of any method invocations that have lead to the call of onConstraintViolation 

thanks in Advance

Alex

[Jens]

Don't enqueue requestContext.saveMember(..).to(..) in the save button ClickHandler. Do it once when you start editing the proxy and in your ClickHandler you only need to do editorDriver.flush().fire().

-- J.

[darre...@gmail.com]

What about if your request context interface has multiple methods?

I have a save and a cancel on mine, and I have to use the cancel to do some server side cleanup if the user decides to abandon their changes. If I call save and it fails validation or whatever, and then the user decides to cancel, then the save method invocation is still present on the request context, when for a cancel call I only want a cancel call in the queue. I really don't understand why there is no API for manipulating the invocation queue, as it seems a valid thing to want to do.

I can probably make a separate context for the cancel, and do it this way, as in that case I'm not interested in anything that has changed in the 'editing' context.....

Is this the right approach?

[darre...@gmail.com]

In fact I can't just make a new context and send cancel(Proxy).fire() to it as the proxy was created by the original request (the one holding the save call in its invocation queue) , and it tries to call edit on the proxy in the GWT internals when I call cancel on the new request (why, I don't know - I only want to pass it across as an argument, and have no intention of editing it in the new context) and then falls over because the proxy was already edited in the original request. 

I guess my cancel will have to take different arguments and do the query for the object I want to get hold of and clean up in my server code (annoying as I'll be duplicating what the find methods on the locator do - albeit my factoring will mean I can do it without duplicating code, but still.....).

Any better ideas anyone?