minor optimization in validation

[claudiobosticco]

Hi, in a test case like the example FSdmiValidation, you can see that a validate request is made, as well as an add request, even if the validation fails (I seem to remember an old thread where you explained why).
But the question is: wouldn’t it be possible to put them in a queue instead?

[Isomorphic]

Not really - when you enter something in the form and then click Submit Order, what you're seeing is the validateOnExit validator firing because the Quantity field lost focus. At that moment, we don't really know that the Submit Order button is going to result in an "add" - it could, for example, refuse to save because of some custom code in the click handler.

The only way to queue these separately triggered requests would be basically to have all requests that result from a single JavaScript thread (the mouseDown event in this case) auto-queue. But that has multiple correctness issues, such as:

1. bundling things into transactions that shouldn't be, causing operations to fail because other, unrelated operations failed

2. bundling slow requests that are expected to run in the background and take 30 seconds with fast requests that were expected to be completed immediately, thereby slowing the UI down

.. and various other scenarios.

However, at the app level, you could get these particular requests to queue, or even skip the validateOnExit logic entirely if the click target is the Submit Order button.

[claudiobosticco]

Hi, thanks for the explanation, and for the heads-up about validateOnExit - it had totally slipped my mind!