That's because when there's an error or violation, the RequestContext is
"un-frozen" and made reusable, but (obviously) not cleared. Given that
Request#fire(Receiver) is equivalent to Request#to(Receiver)+Request#fire()
(where Request#fire() is equivalent to RequestContext#fire()), what you're
doing here is equivalent to:
First time:
context.getItem("id").to(new Receiver());
context.fire();
Second time:
context.getItem("id").to(new Receiver());
context.getItem("id").to(new Receiver());
context.fire();
Third time:
context.getItem("id").to(new Receiver());
context.getItem("id").to(new Receiver());
context.getItem("id").to(new Receiver());
context.fire();
Each time, you "enqueue" a new *invocation* with its own new Receiver, and
because validation is done between processing *operations* and *invocations*,
the violations are reported to each and every Receiver on the client-side.
If you put a break-point in your Receiver, you'll see that each onViolation
call is made on a distinct Receiver instance.
So, what should you do?
Rule of thumb: if you somehow process violations, make sure you "enqueue" *
invocations* once only and only re-fire().
In samples using RF with Editors for instance (DynaTableRf, Expenses),
you'll see that the call to save()/persist() is *enqueued* very early
(sometimes even before the RequestFactoryEditorDriver#edit() method is
called) and when clicking the "save" button it only fire()s the
RequestContext.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
