[Blama]

Hi all,

I just noticed that ValuesManager.checkForValidationErrors() that takes a CallBack was added in 12.0p. Same for ValuesManager.valuesAreValid(), like written in #17.

Best regards
Blama

[Isomorphic]

Hi Isomorphic,

I bumped into this one again today and wanted to let you know that this is still missing, also in the 12.0d docs. No blocker for me, as there are workaround in my case, but would it be good to have that API nevertheless.

Best regards
Blama

Actually, the API you requested, ValuesManager.addAsyncValidationReplyHandler(), was added within a month of your post #14 in 2016, is in SGWT 6.0p 2016-04-15 and indeed you can see the API there now by following the original documentation link you posted.

Also, the valuesAreValid() you mention in #14 is also only on DynamicForm and not on ValuesManager.

This one does appear to be missing, so we'll add it.

[Blama]

Also, the valuesAreValid() you mention in #14 is also only on DynamicForm and not on ValuesManager.

[Blama]

Hi Isomorphic,

I bumped into this one again today and wanted to let you know that this is still missing, also in the 12.0d docs. No blocker for me, as there are workaround in my case, but would it be good to have that API nevertheless.

Best regards
Blama

[Blama]

Yes, it makes sense for ValuesManager to have those same APIs for async validation, we'll get those added.

That's great, thanks.

Note, another API you may have missed is valuesAreValid(), which is a way to determine if client-side validators would all pass, without displaying errors if they would not.

I really did not see valuesAreValid(), thanks.

Best regards
Blama

[Isomorphic]

Yes, it makes sense for ValuesManager to have those same APIs for async validation, we'll get those added.

Note, another API you may have missed is valuesAreValid(), which is a way to determine if client-side validators would all pass, without displaying errors if they would not.

[Blama]

Hi Isomorphic,

it turns out I can't use DataSource.validateData() out of the box, as my clientside restrictions are more restrictive than the server ones.
I could overwrite validate() in my DMI, but don't like to do that (much boilerplate code in my case).

This is my new pseudocode for validation errors:

• if(!validate()) to change the tab icon for clientside validation errors (ValuesManager and DynamicForm)
• Forms now have AsyncValidationReplyHandler to do the same in case of server side validation errors (DynamicForm only)

This is my code to trigger validation of all changed tabs and to trigger saving after successful validation (client+serverside (if needed));

RPCManager.startQueue();
for (DETAILTYPE dt : DETAILTYPE.values())
    if (hasChanges(dt))
        validateData(dt, mode);
if (RPCManager.hasCurrentTransactionQueued()) {
    RPCManager.sendQueue(new RPCQueueCallback() {
        @Override
        public void execute(RPCResponse... response) {
            doSave(mode); //starts save-Queue
        }
    });
} else {
    RPCManager.cancelQueue();
    doSave(mode); //starts save-Queue
}

It seems to be working and I should be fine for now.
The only problem I'm seeing is that ValuesManager currently does not have addAsyncValidationReplyHandler(). This will become a problem once I have a ValuesManager that requires serverside validation.

Could you therefore also log ValuesManager.addAsyncValidationReplyHandler() as a low priority enhancement?

Best regards
Blama

[Blama]

Hi Isomorphic,

I'm using the Queue to save HTTP requests, I'm not interested in separate transactions in this particular case (see above "Other requests not persisted, even though they do not have problems").

I'll go for the two-Queues solution then.

Can you log DynamicForm/ValuesManager.validate() with a Callback as an low-priority enhancement?
Also, is there a way to know in code (not from looking at the .ds.xml) if a call to validate() will require server-validation?

Best regards
Blama

[Isomorphic]

Not saving data when there is an error is presumably a desirable result of using a transaction, right? If it's not, use two (or more) separate transactions.

As far the error message appearing, you could add code to suppress or modify the message shown for transaction failure - in any case you're going to need some kind of handling of that failure, since you presumably need to move the user to whatever form had the validation error that aborted the transaction.

If for whatever reason you prefer to do two separate operations, yes, you have the right idea.

[Blama]

Hi Isomorphic,

yes, that is one part of the problem:

1. Transaction failed popup where I'd only expect a Validation error
2. Other requests not persisted, even though they do not have problems

I think I could do a combination of

• Queue with DataSource.validateData(Record values, DSCallback callback)
• DynamicForm.setErrors(java.util.Map errors, boolean showErrors) in the Callback
• Queue to save() the error-free Forms

Is that what you suggest?

Best regards
Blama

[Isomorphic]

It's not clear why it's a problem that the whole queue fails in this case. Is the issue that, beyond seeing a validation error, the user also sees messages for the other operations failing?

To perform server-side validation "silently" (where errors, if any, will not be shown to the user) and have a callback for completion, you can just take the values from the form or ValuesManager and call DataSource.validateData().

[Blama]

Hi Isomorphic,

I'll continue discussion for

We clarified some of the usage of validateData() in your other thread, covering that it's a rarely used API (arguably even superseded entirely by new behaviors of validate()).

validateData() performs client-side validation first, and returns false if a client-side validator fails. In this case no server request will be issued so your callback won't fire. Currently, the SGWT API for validateData() doesn't actually return a boolean value, so you can't detect this scenario - we're fixing that. We'll also be fixing the issue where two requests can be sent.

Having said all that - what are you actually trying to accomplish? It's unlikely that validateData() is the right API, as improvements elsewhere in the framework have rendered it mostly inapplicable - we might even deprecate it.

and this thread here.

I think as well that validateData() is not the right API for me, as I want to display server validation errors as well.
With the change of the return type from void to boolean I could do this manually, but I'd like using validate() better.

For this it would be great to have

• validate() and ValuesManager.validate() to be boolean (already that way)
• validate() and ValuesManager.validate() support a DSCallback

For me, it would be OK with the Callback not being called in the case of client-validation failing (should be mentioned in the Docs then).
I don't care for a validateHiddenFields-version with a Callback or at ValuesManager.
Minor: I noticed the ValueManager uses java.lang.Boolean while DynamicForm uses primitive data type boolean.

What I want to accomplish is to do validation and only save if there are no errors. In this thread I have the following problem.
Pseudocode:

1. Start Queue
2. For all changed Forms/ValuesManagers, call validation, if it passes, save
3. Send Queue

My problem is that if a changed form includes a serverside-validator and only this one fails, the whole queue fails.
In case of a clientside-only validation the form would not be saved, therefore not be in the queue, therefore the queue would succeed and only the erroneous form would not be saved.

So what I want to do is

1. Start "validation" Queue
2. For all changed Forms/ValuesManagers, call validation
3. Send "validation" Queue
4. Start "save" Queue
5. For all changed and error-free Forms/ValuesManagers, call save
6. Send "save" Queue

I can build a test case in the mentioned thread if needed.

Best regards
Blama

[Isomorphic]

validateData() is a rarely used API - we're going to add more to it's JavaDoc:

<code>validateData()</code> checks for errors in server-side validators without applying such
errors to the form. Errors, if any, can be discovered by looking at the
<code>DSResponse</code> object returns in the callback.
<p>
<code>validateData()</code> will first call +link{validate()} to check for client-side errors,
which will cause such errors to be displayed if present. To avoid this and purely perform
silent, server-side validation, you can use +link{dataSource.validateData()} with the form's
+link{getValues(),current values}.

[Blama]

Hi Isomorphic,

could you explain the difference between DynamicForm.validate() and DynamicForm.validateData() (post #3).
Also validateData(DSCallback callback) is missing javadoc-content.
Also (minor) validate() is somewhere in the docs, not next to the other validation-methods. Normally you have similar methods doc'd together.

Best regards
Blama

[Blama]

Hi Isomorphic,

I'm preparing a testcase in a similar area and found this thread. It has no priority for me, but it seems the APIs are still missing.
This is DynamicForm:


ValuesManager has only validate().

Best regards
Blama