Hi Sammy,
the WITH does just evaluate / "return" an "intermediate" value that is then further "processed" by the "DO" part. "Processing" means "putting that value into other properties".
Maybe the documentation is not that straight forward here but I always explain it as a simple value assignment, regardless if you use it for validation or not.
The above rule can be noted as pseudocode, something like:
text_A.valid = !(text_A.empty == text_B.empty)
text_B.valid = !(text_A.empty == text_B.empty)
\--- DO ---/ \-------- WITH ---------------/
... with the special case / feature here that with the rule syntax you can "write" the value from the WITH to more than one "target" in just one rule. And - by the way - for boolean values you can also use a <NOT> inside the DO (or just for parts of it) - this way you need only one rule if - for example - two fields should behave "oppositely" concering their visibility.
Highlighting fields and forbidding saving/releasing is then a consequence of the applied "validity status" and scope.
Some additional details concerning validation
For "normal" properties (not containing validation!), each property has (or should have...) one defined value at the end - that's the reason why rules without validation should always be "consistent" - meaning without contradictions between rules. A negative example would be two rules that - at the "same time" - evaluate different values for a boolean and write that one to the VISIBLE property of the same input component.
For validation rules, that's a little different. Here, the VALID property of an input component is kind of bound to the "combination" of the rule and the input component, so one input component can have a "combination" of validity states - each of them referring to a rule.
The decision if the input component is then "effectively/finally" considered valid or invalid and - if invalid - in which scope (save, release) with respect of the "behavior" (highlighting, no saving/releasing possible) is then "afterwards" made by the "hightest scoped rule(s) considering it invalid". If there is more than one (e.g. two rules that consider an input component invalid for scope "save"), their messages are even combined.
This allows you to define your validation rules in a more fine granular way to make them easier to implement and also (and that's the more important reason in my opinion) to provide better / more helpful feedback to the editor.
Example:
A text input is used for an URL. In the example, it should be a mandatory field and must start with http:// or https:// and may not contain spaces. If any of those restrictions is not satisfied, the field should be considered invalid in scope "SAVE".
You can of course define just one rule with one regex (or multiple regexes combined with <AND>) covering all restrictions in that one rule and a validation message like "The URL must not be empty, it must not contain spaces and must start with either http:// or https://"
But does not really tell the editor what to change/do.
So from an UX perspective, it might be better to define three independent rules:
- One just with the empty check and a message like "Please fill in an URL"
- Another checking only for https:// or http:// - message "Please add either http:// or https:// at the beginning of the URL"
- A third one checking for spaces - message: "The URL contains at least one space character, please remove spaces"
These rules may "set" the <PROPERTY name="VALID" source="st_url" /> "differently" inside the VALIDATION part, but in this case that's not considered a "contradiction" as they are just defining "their individual" validity status concerning "their" restriction/requirement. The field itself would only considered valid if all ruled set "their" VALID property to true (or - to be more precise - if none of them sets it to false).
If - for example - you enter an URL like "http:/e-spirit. com", the first rule would consider the field valid (restriction "not empty" is satisfied), but the other two would not. So the URL field would be marked red, you could not save the form and both validation messages would be shown. As soon as you remove the space before "com", that "don't use spaces" message would disappear, but the red highlighting and the "start with http:// or https://" message would still be displayed and you still couldn't save the form. Only when you also add the missing "/" (and maybe also an s) everything is "valid" and you can save.
I hope this is understandable 🙂
Michael
