Usage Question: Validator dependentFields, applyWhen, validate whole row

[Blama]

Hi Isomorphic,

the docs list a Validator property dependentFields:

User-defined list of fields on which this validator depends. Primarily used for validators of type "custom" but can also be used to supplement applyWhen criteria.

Can you give an example what this used for? I already do have $record in a Velocity Validator and Map record a DMI Validator. Also, what is "applyWhen"? It is not linked.

My usecase is that I have a Table Check Constraint in the DB in the form of

(fieldA IS NULL AND fieldB IS NULL AND fieldC IS NOT NULL)
OR
(fieldA IS NULL AND fieldB IS NOT NULL AND fieldC IS NULL)
OR
(fieldA IS NOT NULL AND fieldB IS NULL AND fieldC IS NULL)

2nd question:
If I do it with velocity, I'll have to copy the same code to all three fields, correct?
If I do it with Java DMI Validation, I have to list the class in all three fields, correct?
Or is there also a way to have a validator per record and not per field (I'm pretty sure it is not, but just to be sure).

Thank you & Best regards
Blama

[Isomorphic]

applyWhen and dependentFields are really not fully documented enough to use. In a future version, this part of the system will be fully documented, for now, it should not be used.

As far as your use case: yes, using either a DMI validator or Velocity expression would require declaring the validator on all 3 fields. An alternative is to perform the validation logic in a custom DataSource, by overriding execute() and running these additional checks for "update" and "add" operations. If the constraint is not met, you could then report it as a general error (not a validation error), which might be clearer, since it is not a field-specific problem.

If you choose to show it as a field-specific problem, you should return a validation error for each of the three fields; this is clearer for the user and for the framework - it conveys that editing any of the 3 fields may fix the problem.

[Blama]

Hi Isomorphic,

great, thank you.

If you choose to show it as a field-specific problem, you should return a validation error for each of the three fields; this is clearer for the user and for the framework - it conveys that editing any of the 3 fields may fix the problem.

So far I chose to use a validator per field as this is more easy in development. Also the other approach would end in SC.warn(), wouldn't it?
Once the user understands the concept of "use only one field" he or she will know the problem once the validation-error exclamation marks are shown, even without waiting for the exclamation-mark-hovers.

I think I spotted a little hole here, perhaps you can log it as minor enhancement (I'm not affected by it):
If I have a field A that has to be populated if another field B is populated, I can do this as ServerCustom validator on field A (RequiredIfValidator seems to be clientOnly).
This works always when the value for field A changes (update) or is set (add). There is no validation for field A in add when the field is null. The only solution currently is to have a validator on field B as well that says "If this is set, also set field A". Problem here is that the error is with field A, not field B.
So perhaps it is a good idea to always run validators - even if the field did not change / is null at start. Then one could put the validator only at field A, where it belongs.
If this is not a good idea as default for some reason, perhaps enable this behavior with a validator or datasource setting.
Or perhaps this is what applyWhen already is going to be for :)

Best regards
Blama

[Isomorphic]

Yes, returning a general error would result in an isc.warn() dialog by default.

Validators cannot be run every single time regardless of whether fields have changed, as this results in both correctness and performance problems in various cases.

Yes, we already have in mind a feature that allows a validator to declare that it should run when other, related fields are edited.